Custom Query (18300 matches)


Show under each result:

Results (76 - 78 of 18300)

Ticket Resolution Summary Owner Reporter
#17159 fixed dojox/mobile (1.9+) API doc fixes and improvements Adrian Vasiliu Adrian Vasiliu

This ticket collects various API doc fixes and improvements for Dojo Mobile 1.9+.

#17204 fixed dojo/ready: in some conditions, it intermittently does not fire on BlackBerry Z10 Adrian Vasiliu

In some conditions, when running on BlackBerry Z10, dojo/ready does not fire. This has been found to hurt only a few of the very numerous dojox/mobile test cases (in dojox/mobile/tests):

  • test_Templated-widgets.html
  • test_ScreenSizeAware-demo-prop.html
  • test_ScreenSizeAware-demo-tag.html
  • (while the other test_ScreenSizeAware-*.html are not affected).

How to reproduce: load the above test files. If the bug hurts, the symptom is radical: nothing is visible, because dojox/mobile/common waits for dojo/ready to turn on the visibility of <body>. If the initial loading is fine, try reloading several times.

Although I can't be sure it's exactly the same issue, I also reproduced using a modified version of dojo/tests/parser/parseOnLoadDeclarativeRequire.html (see the attached testReady_BB-Z10.html). This page displays "ready: true" if all good, and "ready: ?" if dojo/ready didn't fire. The trouble hurts less often than for the dojox/mobile tests (sometimes after a few reloads, sometimes up to 10 or 15 reloads).

In case it can ring a bell about the kind of race condition hurting here: when reloading repeatedly testReady_BB-Z10.html, you can see in the page the moment when dojo/domReady and dojo/ready fire: most of the time both come quickly, sometimes domReady fires with a few seconds delay but dojo/ready first shortly after it, and in the failing cases domReady is late and dojo/ready never fires...

Another possibly related case: in dijit/tests/_BidiSupport/layout/AccordionContainer.html the page should show "Errors: 0" and "Failures: 0" while it sometimes show a question mark on Z10.

Some potentially useful elements:

  • Reproduced on BB Z10 model STL100-2, OS:, using 1.9.0 and a recent trunk.
  • Did not reproduce using a Z10 simulator.
  • Did notreproduce with the real device in debug mode (connected to a remote webinspector).
  • Did not reproduce on Android or iOS devices, nor on older BB versions, nor on desktop browsers (including IE9).
  • Reproduced on the device with both a) wifi connection (via a hotspot) to a local machine hosting the code and b) using GSM data connection and loading the tests from
  • Async:true matters. Did not reproduce after turning it to false.
  • Auto-require does not matter. Some (but not all) of the failing tests partially rely on auto-require, but pre-requiring all modules does not solve the issue.
  • Automatic vs. manual parsing does not matter. Also reproduced with manual parsing.
  • Apparently this is not due to exceptions during in domReady's or ready's callbacks. (tested using an alert() in a try/catch for the calls from dojo/ready and dojo/domReady).
  • Apparently it is a regression since 1.8.3. (Tried some of the tests without reproducing). Still reproducible with dojo.js, domReady.js and ready.js as of July 2012.
  • Might be related with #16389, while not many signs it would be related with the recent #17146.
#17229 fixed dojox/mobile/Overlay: when used inside a ScrollableView, the Overlay can appear at a wrong location thus being invisible Sebastien Brunot Adrian Vasiliu

When a dojox/mobile/Overlay is used inside a dojox/mobile/ScrollableView, showing the opener can make it appear at a wrong location, outside of the visible area.

How to reproduce:

  1. Open on Safari (iPhone or iPad)
  2. Scroll the view down to the field and tap it.

==> The opener is displayed above the field, not at the bottom of the screen but at the top of the page thus in an invisible area...

Issue initially reported by Sebastien Brunot in a comment of #13865. Since it is a distinct issue, I create a separate ticket for it.

Note: See TracQuery for help on using queries.