Opened 6 years ago

Closed 6 years ago

#17204 closed defect (fixed)

dojo/ready: in some conditions, it intermittently does not fire on BlackBerry Z10

Reported by: Adrian Vasiliu Owned by:
Priority: high Milestone: 1.9.2
Component: Loader Version: 1.9.0
Keywords: bb10 Cc: bill, Patrick Ruzand, ben hockey, Ed Chatelain
Blocked By: Blocking:

Description (last modified by 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: 10.0.10.90, 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 http://archive.dojotoolkit.org.
  • 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.

Attachments (4)

testReady_BB_Z10.html (2.3 KB) - added by Adrian Vasiliu 6 years ago.
Test case for reproducing - modified version of dojo/tests/parser/parseOnLoadDeclarativeRequire.html.
Capture.PNG (32.6 KB) - added by cjolif 6 years ago.
bb_test_case.tar.gz (21.5 KB) - added by Bryan Forbes 6 years ago.
NewCapture.PNG (3.9 KB) - added by cjolif 6 years ago.

Download all attachments as: .zip

Change History (26)

Changed 6 years ago by Adrian Vasiliu

Attachment: testReady_BB_Z10.html added

Test case for reproducing - modified version of dojo/tests/parser/parseOnLoadDeclarativeRequire.html.

comment:1 Changed 6 years ago by Adrian Vasiliu

Cc: bill added

comment:2 Changed 6 years ago by Adrian Vasiliu

Description: modified (diff)

comment:3 Changed 6 years ago by Adrian Vasiliu

Since the issue only reproduces on the real Z10 device, not on simulators, if there are some specific debugging actions that I can do on the device and you don't have access to a Z10, don't hesitate to ask me.

As said in the description, remote debugging via webinspector during the loading phase is not an option, because the issue doesn't hurt in this case... Available debugging options include alert()-based debugging, and instrumenting the code to store debugging info in global variables that can be accessed when connecting webinspector after the loading phase.

comment:4 Changed 6 years ago by Adrian Vasiliu

Cc: Patrick Ruzand added

comment:5 Changed 6 years ago by cjolif

We have a users hitting this in particular when embedding his app in Cordova (specific to BB10).

comment:6 Changed 6 years ago by cjolif

Priority: undecidedhigh

comment:7 Changed 6 years ago by cjolif

after more investigations this is a BlackBerry? 10 JavaScript? VM bug that is hurting the loader in some cases. I will issue a pull request with a workaround for the VM bug.

comment:8 Changed 6 years ago by cjolif

Keywords: bb10 added

comment:9 Changed 6 years ago by Bryan Forbes

I am unsure if the fix actually fixes the bug at hand or if it's working around an issue with some code inserting undefined/falsey values into what the loader is iterating over. To test if this is actually a BB10 VM issue, could you try the following code?

var array = [1, 2, 3];

for (var i = 0; array[i]; ) {
    alert(array[i++]);
}

This should alert 3 times with 1, 2, 3 being the output. Then check the following:

var array = [1];
array[2] = 3;

for (var i = 0; array[i]; ) {
    alert(array[i++]);
}

This should only alert once. If these tests succeed on BB10 (I assume they will), then their JS VM is fine and something is feeding improper values to the loader somewhere.

comment:10 Changed 6 years ago by cjolif

Well obviously your test case is working because the VM bug requires a more complex environment to be triggered. I have debugged it and I can assure you I don't have a undefined/falsy value but still failing (otherwise I would not have proposed that fix).

comment:11 Changed 6 years ago by Colin Snover

What does the console say the value of array, i, and array[i] are when this is failing?

comment:12 Changed 6 years ago by cjolif

First my test case reduced down to something like:

require(["dojo/when", "dojo/on", "dojo/dom-attr", "dojo/_base/declare"], 
  function() {
	require(["test/Test1", "test/Test2"], function(){
		window.alert("receive my specific require");
	});
});

with test/Test1 & 2 being identical:

define([], function(){
	
});

under that condition if I modify dojo.js to put the following traces in forEach:

forEach = function(vector, callback){
	if(vector){
		var m;
		for(var i = 0; vector[i];){
			console.log(i);
		        console.log(vector);
		        //	console.log(vector[i].mid);
			callback(m = vector[i++]);
		        console.log(m.mid);
		}
	}
},

here are the trace I'm getting. You see the second m.mid is identical to the first one while it should not be and is not with my patch:

If I add back the trace in commment the problem disapears, same thing if I enable the remote web inspector debugging on etc... in other words this is a tricky VM bug as we find from time to time that my patch is workarounding.

Last edited 6 years ago by cjolif (previous) (diff)

Changed 6 years ago by cjolif

Attachment: Capture.PNG added

Changed 6 years ago by Bryan Forbes

Attachment: bb_test_case.tar.gz added

comment:13 Changed 6 years ago by Bryan Forbes

I just attached a test case. Untar that in the parent directory of a checkout of Dojo and hit test_bb.html from your device. It should produce two alerts: "0: test/Test1" and "1: test/Test2". I patched dojo.js to include alerts for only the test modules. I ran this in the simulator and it works, but Adrian says that this isn't a problem in the simulator so I'd like him to try this on his device. Let's work from this test case and see if we can nail down if this really is a VM problem. If it is a VM problem, then we need to file a bug with BlackBerry? because even IE gets this right.

comment:14 Changed 6 years ago by ben hockey

Cc: ben hockey added

comment:15 Changed 6 years ago by cjolif

Adrian is on vacation and the device he used is anyway the same device (Z10) I used to reproduce this customer issue so I'm not sure it will help as obviously I do reproduce it ;)

(and yes the problem does not appear on simulator, and my own problem only happens when embedding the app in WebWorks?)

In any case even if submitting the bug to BlackBerry? is indeed a good idea, this won't solve our issues... so I don't really understand all of this. How could this not be a VM bug (see my traces and how little changes to the code just make the problem vanishes, this is typical of such issues).

comment:16 Changed 6 years ago by cjolif

I was asked for additional tests at yesterday meeting to confirm the VM origin of the error. Here are the results.

1/ use of stringify to avoid wrong interpretations of console.log(vector). I was not able to use directly stringify as-is because there are circular references in the object to output and so stringify is failing. That said I have done:

forEach = function(vector, callback){
	if(vector){
		var m;
		for(var i = 0; vector[i];){
			console.log(i);
			console.log(JSON.stringify(vector, ["mid"]));
			m = vector[i++];
			console.log(m.mid);
			callback(m);
			console.log(m.mid);
		}
	}
}

so we can see the mid of each item in the vector and the result is the following one which basically confirms what was shown by console.log(vector):

No image "NewCapture.png" attached to Ticket #17204

The array contains Test1 & Test2 but still in the loop I get twice Test2 whether I display it before or after the callback.

2/ replace dom-attr with another module with no circular dependencies to see if the problem persists. Removing dom-attr indeed "solves" the problem. That said all of this is proving to me is that the VM bug only occurs in that specific complex context. The traces listed in 1/ seem pretty clear to me.

Last edited 6 years ago by cjolif (previous) (diff)

Changed 6 years ago by cjolif

Attachment: NewCapture.PNG added

comment:17 Changed 6 years ago by Ed Chatelain

Cc: Ed Chatelain added

comment:18 Changed 6 years ago by bill

I agree, looks like a VM bug, and I think the practical solution is to check in Christophe's fix.

comment:19 Changed 6 years ago by Ed Chatelain

There were no objections to committing Christophe's fix at the dojo-meeting today, so I will commit it tomorrow, unless someone objects before I do it.

comment:20 Changed 6 years ago by Ed Chatelain <ed.chatelain@…>

In ded3e6d2fcc6abf35eaa9a23eea96e30b34d372e/dojo:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:21 Changed 6 years ago by Ed Chatelain <ed.chatelain@…>

In 267bb77eaee81f29f4f18dc014d766a862e87707/dojo:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:22 Changed 6 years ago by Ed Chatelain

Milestone: tbd1.9.2
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.