Closed Bug 418574 Opened 13 years ago Closed 12 years ago

List items can be misplaced if <ol> "start" or <li> "value" attributes change

Categories

(Core :: Layout, defect, P2)

defect

Tracking

()

RESOLVED DUPLICATE of bug 203727
mozilla1.9.1b3

People

(Reporter: jruderman, Assigned: smontagu)

References

(Blocks 1 open bug)

Details

(Keywords: regression, testcase, verified1.9.1)

Attachments

(8 files)

The testcase and reference should look the same.  refdyn found this bug thanks to layout/reftests/bidi/413928-2.html.
Attached file testcase
Attached file reference
Attached image Screensho on windows
At WinXP, at first drawing, testcase and reference is NOT look the same.
But, After changing width of window, both looks the same.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021904 Firefox/3.0b4pre
Based on the regression date (2006-12-08), this is a regression from reflow refactoring.
Keywords: regression
OS: Mac OS X → All
Hardware: PC → All
layout regression, should probably block
Flags: blocking1.9?
Nothing really bidi about this, except that the testcase has dir="rtl". There are cases of the same bug in ltr. 
Component: Layout: BiDi Hebrew & Arabic → Layout
QA Contact: layout.bidi → layout
Do you have a testcase that demonstrates the bug without dir="rtl"?
Attached file ltr testcase
Assignee: roc → smontagu
Status: NEW → ASSIGNED
Summary: RTL list items are misplaced if <ol> "start" attribute has changed → list items are misplaced if <ol> "start" attribute has changed
Summary: list items are misplaced if <ol> "start" attribute has changed → List items can be misplaced if <ol> "start" or <li> "value" attributes change
From IRC:
<smontagu> i think i have a oneline fix for it
           namely to do FrameNeedsReflow instead of Invalidate at http://mxr.mozilla.org/seamonkey/source/layout/generic/nsBlockFrame.cpp#6522
           does that make sense?
<roc>      i guess ... we changed the number, so the frame size needs to change?
           except you can't call FrameNeedsReflow during reflow
           you need to do it as a post-reflow callback
           not sure what that would do to Tp
<smontagu> I don't think this is during reflow
<roc>      sure is
           http://mxr.mozilla.org/seamonkey/source/layout/generic/nsBlockFrame.cpp#915
           I wonder why we don't renumber lists after restyle/frame construction
           ask bz
           or dbaron
<smontagu> it also gets called from AttributeChanged
           which is the one that the testcase hits
<roc>      okay but you can probably cook up a testcase that hits it during reflow
           e.g. set things up so removing an element from the tree causes the bullets to renumber the same way
           or adding one
For the record, only the first testcase is a regression. The others have been broken since forever (tested in a build from 20010131).
Yeah, doing list numbering during reflow sucks.  My long term plan is to switch lists to using counters, which are processed at frame construction time.  I think there's even some work-in-progress lying around in a bug somewhere, but it's too big a project for 1.9 at this point.
Flags: wanted1.9+
Flags: blocking1.9?
Flags: blocking1.9-
Priority: -- → P2
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
Duplicate of this bug: 466689
Can anyone still reproduce this on mozilla-central trunk? All the testcases seem to work for me.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 203727
Attached patch reftest diffSplinter Review
Attachment 305283 [details] is equivalent to layout/reftests/bugs/203727.html, but I think the other ones are sufficiently different that it's worth checking them in.
Checked in reftests to trunk as http://hg.mozilla.org/mozilla-central/rev/2c8799d7166e
Flags: in-testsuite+
Keywords: fixed1.9.1
Target Milestone: --- → mozilla1.9.1b3
marking verified1.9.1 on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090130 Shiretoko/3.1b3pre Ubiquity/0.1.5.   

However, im a little perplexed why the fixed1.9.1 keyword was added here, and not in bug 418574 instead.  Since this was marked as a dupe of it.
You need to log in before you can comment on or make changes to this bug.