Closed Bug 481869 Opened 15 years ago Closed 15 years ago

TM: serious layout issues for complex widgets, involving JS and DOM interaction, with JIT enabled

Categories

(Core :: JavaScript Engine, defect, P1)

x86
Windows XP
defect

Tracking

()

RESOLVED DUPLICATE of bug 479198

People

(Reporter: helder.magalhaes, Assigned: gal)

References

()

Details

(Whiteboard: regression, regression-window-needed)

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090305 Minefield/3.2a1pre

JIT seems to be interfering with JavaScript-based DOM manipulation. In the experienced cases, there seem to be DOM nodes missing.

Reproducible: Always

Steps to Reproduce:
1. Open the report's URL;
2. Give focus to the canvas by clicking anywhere on the canvas;
3. Place the mouse pointer over the several "Hover me" buttons;
4. Toggle "javascript.options.jit.content" state in "about:config";
5. Reload the page;
6. Repeat steps 2 and 3.
Actual Results:  
Whenever JIT is disabled, result is the expected.

Results are incoherent whenever JIT is enabled:
a. Sometimes images and/or text is missing;
b. Sometimes the tooltip content doesn't appear to be inside the canvas (a small canvas rectangle is displayed next to the content).
c. Sometimes no tooltip is displayed (though this is hard to reproduce);

Expected Results:  
HTML-based tooltips with textual or rich (HTML-based) content would be displayed.

By using the report's URL, one may also reproduce this by placing the mouse over the item list displayed left (which also contains similar HTML-based tooltips).

This was already noticed for some time (since 2008-12-03 [1]) in nightly builds with JIT enabled. Nevertheless, I haven't been able to reduce to a simple HTML+JS (without any other dependency) yet: I'm reporting this in the hope that someone may be able help hunting this down.

By using the DOM inspector (2.0.3), it sounds like there are DOM nodes missing. The code makes extensive use of on-the-fly markup generation and "innerHTML" so my current guesses are differences between JIT and regular interpretation regarding:
 * String manipulation;
 * "innerHTML"-related;
 * Handling concurrency (as things seem to be ran in several contexts concurrently).

Also, this may be related with bug 451843, where somehow similar behavior is described (although the Ubiquity extension is apparently required there). Background information and more ways to reproduce (potentially) related issues are available [1].

Finally, it doesn't seem to be possible to use Firefox's safe mode (firefox.exe -safe-mode) to try understand if this related to some add-on due to bug 478846)...

Screenshot snippets of the expected vs. observed behavior will follow.

[1] http://bugzilla.qooxdoo.org/show_bug.cgi?id=1664
Attached image Expected behavior
An attached single-file test case that we can work to reduce would be amazingly helpful, if you're able to reduce it that far.  Thanks for the report!
(In reply to comment #5)
> An attached single-file test case that we can work to reduce would be
> amazingly helpful, if you're able to reduce it that far.

I'm planning to work on that whenever possible, although I really wanted to report this as Firefox 3.1 -- or should I say 3.5 [2]? ;-) -- is already in Beta3 and I'm afraid that, if this isn't properly hunted down (and/or confirmed to be a false alarm, of course), multiple rich Web applications may break with the upcoming release... :-|

Setting as a blocker of bug 451602 as this seems to be a TraceMonkey
regression.

[1] http://developer.mozilla.org/devnews/index.php/2009/03/05/firefox-31-may-become-firefox-35/
Blocks: 451602
Yes, definitely something we need to fix before shipping Firefox 3.5.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.1+
We are seeing this in our qooxdoo based rich web app as well. We're seeing the
tooltip problem as well as intermittently in other situations like:

1) popup menus appear with missing menu items or sub-menus. Closer inspection
reveals that there are elements missing at the DOM level
2) images in buttons sometimes don't appear at all
3) tables sometimes don't appear at all

As reported, turning off the JIT yields correct rendering and behavior.  I also
suspect that this is indicative of problem that may affect other highly dynamic
RIA's. Having this fixed for FireFox 3.1 would be great!
The bug can also be observed in the demo browser of the current qooxdoo 0.8.2 release <http://demo.qooxdoo.org/current/demobrowser/>. With JIT enabled this application won't even start up. I've traced this problem in the "uncompiled" version of this application to the following lines of code (qx/core/Widget.js:1736):

    addChildrenToQueue : function(queue)
    {
      var children = this.__widgetChildren;
      if (!children) {
        return;
      }

      var child;
      for (var i=0, l=children.length; i<l; i++)
      {
        child = children[i];
        queue[child.$$hash] = child;

        child.addChildrenToQueue(queue);
      }
    },
    
    
  FireFox reports a "undefined has no properties - [Break on this error] for (var i=0, l=children.length; i<l; i++)" error. And now the fun part: If I put a "console.log(children)" statement just in front of the loop the problem is gone and the app starts up cleanly.
  
I've observed this with:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090308 Minefield/3.2a1pre

3.1b2 works fine.
Fabian, the statement probably inhibits native code generation around that loop. If you could help me reproduce this bug locally, that would be great. Also, could you insert an alert(uneval(children)) in there right before the loop and post the result? Thanks.
Assignee: general → gal
Priority: -- → P1
Sure,

this is how you can reproduce my setup:

1. Download and unzip the qooxdoo SDK <http://downloads.sourceforge.net/qooxdoo/qooxdoo-0.8.2-sdk.zip>
2. cd qooxdoo-0.8.2-sdk/application/demobrowser
3. ./generate.py source-script  (this step requires Python)
4. open source/index.html

The error orrurs at qooxdoo-0.8.2-sdk/framework/soure/class/qx/ui/core/Widget.js

alert(uneval(children)) gives me the following error:
"String.prototype.toSource called on incompatible Object"

BTW: What does the uneval function do?
this WFM on trunk. reopen if you can still reproduce.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Seems to be fixed now. With the nightly version the problems are gone.
Its not clear to me what fixed this. If anyone gets around to bisecting this that would be great.
Whiteboard: regression-window-wanted
(In reply to comment #12)
> this WFM on trunk. reopen if you can still reproduce.

I was still able to reproduce using a nightly build [1], at least on Windows XP SP3. Not the symptom on comment 11, which was pretty weird (but potentially unrelated) but the original issue reported (comment 0), slightly modified due to a new, apparently unrelated, issue introduced.

Steps to reproduce:
1. Open the issue's URL;
2. Press the play button in the top menu (this is required in nightly versions due to a strange error [2] displayed on Error Console, current release [3] doesn't need this step);
3. Mouse over the "Hover me" buttons.

I can still consistently reproduce the issue with the tooltips of the red and yellow "Hover me" buttons, as well as tooltips shown while hovering the left navigation tree items and also the action buttons (play, fast forward, previous/next and reload).

[1] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090316 Minefield/3.2a1pre
[2] Error: Could not find iframe which was loaded [B]!
    Source File: http://demo.qooxdoo.org/0.7.4/demobrowser/script/demobrowser.js
    Line: 22218
[2] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7 (.NET CLR 3.5.30729)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
works:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081027 Minefield/3.1b2pre ID:20081027021004
http://hg.mozilla.org/tracemonkey/rev/a14880ce7249
fails:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081028 Minefield/3.1b2pre ID:20081028020858
http://hg.mozilla.org/tracemonkey/rev/ee65962d23e4

=> range:
http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=a14880ce7249&tochange=ee65962d23e4

works:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081107 Minefield/3.1b2pre ID:20081107043838
http://hg.mozilla.org/mozilla-central/rev/18fec592b35b
fails:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081108 Minefield/3.1b2pre ID:20081108033239
http://hg.mozilla.org/mozilla-central/rev/17747605490c

i had to set javascript.options.jit.chrome *and* javascript.options.jit.content to "false" to verify that it's working without JIT enabled.

=> range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=18fec592b35b&tochange=17747605490c
Status: REOPENED → NEW
Whiteboard: regression-window-wanted → regression
Version: unspecified → Trunk
The merge contains a large number of TM fixes. Can you try to narrow it down a bit more?
if you look at the (relevant) intersection of both ranges there are two bug landings (TM -> MC) that are in common:
bug 450833 and bug 458851.

of course i'd rather like to run hg bisect to be really sure, but i got no build environment. perhaps somebody else can step in here?
Whiteboard: regression → regression, regression-window-needed
I've noticed an additional potential regression recently [1] (which I'm not positive if it has been there from the start): There are now several items missing in the left navigation panel. For example, only "Table 2" and "Table 4" are shown, when there is a whole set ranging from 1 to 5. Setting "javascript.options.jit.content" seems to workaround the missing items (as reported in previous comments). The cause is likely the same (missing DOM nodes due to some TM misbehavior).

[1] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090402 Minefield/3.6a1pre
As far as I can tell this is a dup of 479198 and is fixed im TM tip. Could someone verify? I will dup it. Please re-open if this still persists.
Status: NEW → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → DUPLICATE
(In reply to comment #20)
> As far as I can tell this is a dup of 479198 and is fixed im TM tip. Could
> someone verify? I will dup it. Please re-open if this still persists.

Great! :-) Just checked that I'm unable to reproduce the symptom(s) reported within this bug report. Thanks for the effort, everyone. ;-)

(Nevertheless, I'm not able to verify this fixed, at least not in the sense of having two builds with and without the changes introduced from fixing bug 479198 and checking that those specifically fix the behavior.)

[1] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090412 Minefield/3.6a1pre
what build can I try to verify this with?  I tried Shiretoko: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090414 Shiretoko/3.5b4pre and it looks like it may still be having problems..
again, turning off jit.content fixed the problem

(In reply to comment #22)
> what build can I try to verify this with?  I tried Shiretoko: Mozilla/5.0
> (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090414
> Shiretoko/3.5b4pre and it looks like it may still be having problems..
(In reply to comment #22)
> what build can I try to verify this with?  I tried Shiretoko: Mozilla/5.0
> (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090414
> Shiretoko/3.5b4pre and it looks like it may still be having problems..

A change [1] (see activity [2] also) in bug 479198 makes me suspect this will likely be available in the next Shiretoko nightly build. Please check again within a couple of days (though a few hours may suffice).

Note that this is for Gecko 1.9.1 -- 1.9.2 already had this issue fixed a few days ago (see comment 21).

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=479198#c46
[2] https://bugzilla.mozilla.org/show_activity.cgi?id=479198
You need to log in before you can comment on or make changes to this bug.