Closed Bug 321738 Opened 17 years ago Closed 14 years ago

Floated LI renders in inconsistent ways, links aren't always active

Categories

(Core :: Layout, defect)

1.8 Branch
x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mike, Unassigned)

References

()

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

The example page should render as a series of rows and columns of UL/LI elements, but when I upgraded from Firefox 1.0.7 to 1.5, it renders differently and acts differently when I access it.  I believe it has something to do with the "float" in the CSS, but I'm not sure.

I think there are two related symptoms of this bug:

1) The rows and columns should fill the page, but it often shows up as a single column
2) The links sometimes refresh the page with a different configuration of rows and columns (rather than sending the user offsite).


Reproducible: Always

Steps to Reproduce:
1. Navigate to http://www.mailoutinteractive.com/TEMP/FireFoxProblem/ConfigureMailinglist.aspx.htm?test1
2. If this renders in one column, try adjusting the parameter (e.g. "test2", "test3" etc.
3. Click on the link.  You *should* go to Google, but it often re-renders the page with one fewere column.  I can sometimes keep clicking-and-re-rendering until there is one column, at which time the links will point to Google.

Actual Results:  
Rendering: the list is sometimes rendered as one column
Links: the links cause the page to re-render

Expected Results:  
Rendering: The  list should fill the page horizontally (as in IE 6 or Firefox 1.0.7)
Links: You should end up at google when you click on the links
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.8 Branch
The testcase exibits very weird behavior, but I think it might have something to do with the ASP script you're using. Could you make a minimized testcase that doesn't use ASP?
Hi-

Actually, it's not using any dynamic code server-side or client-side.  The example started out life as an ASPX file (hence the .aspx.htm extension), but I saved it as a pure html+css file (and reduced its size by about 95%), and there is no dynamic content left.  (The querystring at the end can be left off.)

What's left seems to be some weird processing of the CSS---almost like its rerendering the css after the click and absorbing the click event.

Thanks!

-Mike
Severity: normal → major
I was revisiting this and wanted to clarify the various potential ways this code is displayed in Firefox 1.5+.  It has the characteristics of a race condition.  
The rendering is different each time I reload, and clicking on a link gives me different results each time.  The following are things that can occur:

LOADING:
1) The icons & labels load in columns, enough to fill the page (as it is supposed to do)
2) The icons & labels load in columns, but not enough columns to fill the page
3) The icons and labels load in a single column

CLICKING:
1) The page does not re-render, and the user is sent to Google (as it is supposed to do)
2) The page re-renders (usually with one fewer column) and then the user is sent to Google
3) The page re-renders but the user is not sent anywhere.

When there is only one column, the user is always sent to Google.  This worked great up until after Mozilla 1.0.7 (and it works ok in IE). 

Hope this helps in diagnosing the problem!

Thanks,

-Mike
WFM in Fx3+, looks like a bug fixed by the reflow refactoring.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
Attached patch reftest (obsolete) — Splinter Review
In Fx2 the list items are in a column, anywhere else they're on the same line.
Attachment #358620 - Flags: superreview?(dbaron)
Attachment #358620 - Flags: review?(dbaron)
Maybe fixed by bug 413840, actually?

I'm not sure I understand how the test is testing the bug.  Did it really go away when the images weren't present?
This was fixed by the reflow branch landing.
Depends on: reflow-refactor
Comment on attachment 358620 [details] [diff] [review]
reftest

Marking review- to trigger a response to my question; feel free to re-request with an answer if you feel no change is needed.
Attachment #358620 - Flags: superreview?(dbaron)
Attachment #358620 - Flags: superreview-
Attachment #358620 - Flags: review?(dbaron)
Attachment #358620 - Flags: review-
Attached patch reftest, v2Splinter Review
(In reply to comment #6)
> I'm not sure I understand how the test is testing the bug.  Did it really go
> away when the images weren't present?

Yes, reliably. Though, now that you mention it, triggering a reflow should be more reliable.
Attachment #358620 - Attachment is obsolete: true
Attachment #359749 - Flags: superreview?(dbaron)
Attachment #359749 - Flags: review?(dbaron)
Comment on attachment 359749 [details] [diff] [review]
reftest, v2

r+sr=dbaron
Attachment #359749 - Flags: superreview?(dbaron)
Attachment #359749 - Flags: superreview+
Attachment #359749 - Flags: review?(dbaron)
Attachment #359749 - Flags: review+
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/aed4d0b8e3b2
Flags: in-testsuite? → in-testsuite+
Keywords: checkin-needed
You need to log in before you can comment on or make changes to this bug.