dojox/mobile/common should be required by dojox/mobile/Opener and dojox/mobile/SearchBox

Description

A number of dojox.mobile modules behave correctly only if dojox/mobile/common has been previously loaded. In most cases, "common" is guaranteed to be loaded before the module which needs it. But there are a few exceptions, where the module does not require "common" directly nor indirectly. Thus, in such cases these modules misbehave due to dojox/mobile/common not being loaded, or being loaded too late. These situations tend to become more frequent with the new auto-require mechanism starting with Dojo 1.8, but it would be the same if the modules used in markup would be required explicitly in the same order as their declarative usage in markup.

The two dojox/mobile modules which need dojox/mobile/common while not ensuring it is loaded (do not require "common" directly nor indirectly):

a) dojox/mobile/Opener uses the CSS class "dj_phone" which is conditionally added to doc.documentElement by dojox/mobile/common.

Load the attached test_Missing_Common.html for instance in Chrome 21 on desktop (ensure the smallest window dimmension is larger than 500 px, since this case should trigger the addition of dj_tablet).

The test displays a text saying whether the CSS classes dj_phone, dj_table, and dj_chrome are present. It displays the values as detected on dojo/ready, and the values after explicitly requiring dojox/mobile/common. You can see the two are different, the values being correct only after requiring dojox/mobile/common.

Notes:

dojox/mobile/common is most often loaded before other dojox/mobile modules, because most apps require the dojox/mobile module (which requires it indirectly) and/or modules such as dojox/mobile/View and dojox/mobile/_base (which require dojox/mobile/common). This is why this bug hurts only rarely.

dojox/mobile/common also provides the "hide address bar" feature, which obviously can't work without this module being required directly or indirectly. Now, since this feature is activated via a data-dojo-config option, we cannot ensure the module is required simply by adding a dependency to some existing module. Here, the best we can do is to improve the documentation (but currently there isn't much documentation about it).

SearchBox is new in Dojo 1.8, so backporting the fix into 1.7.x is pointless. But Opener is already present in 1.7.x, so backporting the fix for it may be welcome.

Good point. Adding a new dependency on common may be a simple and workable solution, but the reason why many dojox/mobile widgets do not have explicit dependency on common is to allow the users to use them for any type of applications including desktop applications. I think Opener can have its own simple logic to determine if the current environment looks like phone or not. The logic may be used only when both "dj_phone" and "dj_tablet" do not exist.

Ok, after massive triage, ended up with about 80 tickets for 1.11 and 400 or so for 1.12. That's a bit unrealistic, so first I changed all 1.12 to 1.13 (with the plan to move some forward to the new 1.12. Now, I'm moving some of the 1.11 tickets that are less likely to get done this month without help to 1.11. Feel free to help out in January if you want to see this ticket land in 1.11.