Closed Bug 1024269 Opened 10 years ago Closed 10 years ago

Win64 REFTEST TEST-UNEXPECTED-FAIL | file:///C:/slave/test/build/tests/reftest/tests/layout/reftests/dom/multipleinsertionpoints-appendsingle-2.xhtml | image comparison (==), max difference: 255, number of differing pixels: 104

Categories

(Core :: XBL, defect)

Product:
Core
Component:
XBL
Version:
32 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1026008

People

(Reporter: away, Unassigned)

References

Details

https://tbpl.mozilla.org/php/getParsedLog.php?id=41405495&tree=Date

I assume the first five failures there share a common cause.
The failures look like we've got the completely wrong content, rather than being e.g. a painting glitch.

e.g. the first failing test, multipleinsertionpoints-appendsingle-2.xhtml, has "21" instead of "12" on the first line, and the second has
 21
 5
 3
 4
...whereas the reference has...
 12
 3
 4
 5

CC'ing tn, who wrote these tests (in http://hg.mozilla.org/mozilla-central/rev/699e6f9a3660 ) & may have some insight.
Depends on: lazyfc
Are these supposed to behave differently in the test environment or something? When I simply load up multipleinsertionpoints-appendsingle-2.xhtml, both win32 and win64 give me:

3
1
4
5
2
Yeah, these testcases use XBL, which is disabled unless you set the pref described in https://developer.mozilla.org/en-US/docs/Using_Remote_XUL

(That pref is set for the reftest environment, and it's also enabled for chrome-privileged content, I believe.)
(In reply to Daniel Holbert [:dholbert] from comment #1)
> The failures look like we've got the completely wrong content, rather than
> being e.g. a painting glitch.
> 
> e.g. the first failing test, multipleinsertionpoints-appendsingle-2.xhtml,
> has "21" instead of "12" on the first line, and the second has
>  21
>  5
>  3
>  4

That ordering is really odd. Obviously XBL is doing something because it pulls the 2 to the start, but in a different order then in in tree before xbl is applied. And then the order of the remaining elements just makes no sense. And the strangest thing is that these tests are passing on win32. Is XBL putting the children in the correct order? Or are we constructing the frames in the wrong order now for some reason? Who knows about XBL these days?
I don't have any ideas offhand.

The way to debug this would be to inspect the DOM in both the win32 and win64 case (to determine if it's a DOM issue or a layout issue). Script from the content scope isn't going to be able to see the anonymous content. The simplest thing is probably just to load this as chrome so that you'll both be able to apply the binding without setting any prefs (see comment 3) and be able to use document.getAnonymousNodes.
It appears to be a problem with the DOM. The DOM Inspector shows the span containing the "2" before the one containing the "1" in a win64 build I downloaded, win32 builds have it correct. Also forcing a full reconstruct (by toggling display: none on/off on an ancestor) doesn't fix the problem, so unlikely to be a problem with incremental frame construction updates.
Component: Layout → XBL
Indeed, and Neil filed the correct bug for us already.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Bug 1026008 has merged to m-c, is it possible to verify the fix on TBPL?
The tests are fine, the bug was in XBL code, so removing dependency on the bug that added the tests.
No longer depends on: lazyfc
(In reply to neil@parkwaycc.co.uk from comment #8)
> Bug 1026008 has merged to m-c, is it possible to verify the fix on TBPL?

This failure no longer appears on the latest Date push. Thanks for the fix!
https://tbpl.mozilla.org/?tree=Date&rev=a2b84c34f2e1
You need to log in before you can comment on or make changes to this bug.