Closed
Bug 321738
Opened 19 years ago
Closed 16 years ago
Floated LI renders in inconsistent ways, links aren't always active
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mike, Unassigned)
References
()
Details
Attachments
(1 file, 1 obsolete file)
1.71 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
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
Updated•19 years ago
|
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.8 Branch
Comment 1•19 years ago
|
||
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?
Reporter | ||
Comment 2•19 years ago
|
||
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
Reporter | ||
Updated•19 years ago
|
Severity: normal → major
Reporter | ||
Comment 3•19 years ago
|
||
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: 16 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
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-
(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
Comment 11•16 years ago
|
||
Flags: in-testsuite? → in-testsuite+
Keywords: checkin-needed
You need to log in
before you can comment on or make changes to this bug.
Description
•