63703 - Race condition in table alignment

Status: VERIFIED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Blake Ross]

Build ID: 12/25 trunk (tip)

Steps to Reproduce:

(1) Go to http://bugzilla.mozilla.org/show_bug.cgi?id=63687 (or any Bugzilla 
bug).
(2) Look at the amount of space between "Description:" and "Opened [date time]".

Result: the two cells are now close together, instead of aligned at the left 
and right ends of the viewport.

Relevant code:

<table><tr><td align=left>Left</td>
<td align=right width=100%>Right</td></tr></table>

This works in a 12/13 nightly, so it regressed sometime since then (when I get 
more time, I'll track it down further).  This is, amazingly enough, a race 
condition, which leads me to believe that this might be a parser bug (dropping 
the |align| attribute sometimes?).  Continuously reload the testcase I'll 
attach and watch as the cells sometime align correctly and sometimes don't.  
Strangely, they never seem to align properly if I keep reloading a Bugzilla 
bug...

Comment 1

[Blake Ross]

Attachment: testcase

Comment 2

[Blake Ross]

[note that it's easier to see them align properly if you save the testcase 
locally and continuously reload it]

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

This seems like it could be related to bug 63445.

Comment 4

[James Green]

Can't see anything wrong after ten reloads of the testcase in linux 2000122406,
however I am seeing wrong alignment on parts of this bug page... Create a new
attactment it left-aligned with the input fields leftmost edge above it, and the
depends on and blocks and votes texts are even further across to the right. In
fact that whole section is aligned to the center of the page.

Comment 5

[Hixie (not reading bugmail)]

(not a parser bug, merely causing an incremental reflow can cause the table
layout to change.)

Note: Based on the number of times it was mentioned on IRC today, this bug is 
headed for mostfreq status pronto. ;-)

Comment 6

[James Green]

Bug 63945 could be reporting this too. Noting it here because the author of that
bug has a couple more testcases, the latter of which he claims has slightly
different behaviour.

Comment 7

[HJ]

Isn't this related to bug 63445??

Comment 8

[HJ]

This must have been fixed with that path of karnaze. I can't repro this on build
2001011220 on WinNT.

Comment 9

[Blake Ross]

Don't see anymore either, marking wfm.

Comment 10

[Amarendra Hanumanula]

QA contact update

Comment 11

[Amarendra Hanumanula]

  
  I dont see the problem anymore.. Marking as verified
 Build ID: 2001052720