Closed
Bug 147894
Opened 22 years ago
Closed 21 years ago
CSS pseudo-element :after for body tag displayed incorrectly on first load if content spans multiple lines
Categories
(Core :: CSS Parsing and Computation, defect, P2)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: daren, Assigned: dbaron)
References
()
Details
(Keywords: testcase)
Attachments
(1 file)
489 bytes,
text/html
|
Details |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 BuildID: 2002051006 If on (re)load the Mozilla window is not wide enough to display the content of the CSS pseudo-element ":after" for the "body" tag in one single line, the content is displayed before the actual body part, instead of after. AFAIK, this concerns only the pseudo-element ":after" for the "body" tag. I checked the paragraph ("p") tag and everything looked fine to me. Also, this does not happen if the content of body:after initially fits one line, and the window is then resized. You'd have to reload the page to observe the faulty behavior in that case. Reproducible: Always Steps to Reproduce: 1. Open the included page in Mozilla Browser 2. If everything looks fine (i.e. the body:after content is displayed after the actual body part), resize window until the body:after content (without the actual body part) does not fit on one line anymore 3. Reload Actual Results: The body:after content is displayed before the body. Expected Results: Display the body:after content after the body. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head> <title>bug reproduction for body:after</title> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /> <style type="text/css"> body:after { content:"This should be appended to body. Instead, when the window isn't wide enough to display in one line, it's prepended."; } </style> </head> <body> <p><strong>Actual body.</strong></p> </body> </html>
Assignee | ||
Updated•22 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → mozilla1.1beta
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla1.1beta → mozilla1.2alpha
Comment 1•22 years ago
|
||
This pretty reliably WORKSFORME on a CVS tip build on a Linux-kernel OS.
Assignee | ||
Comment 2•22 years ago
|
||
No, I'm still seeing this on Linux.
Severity: normal → major
OS: Windows 2000 → All
Priority: P3 → P2
Hardware: PC → All
Target Milestone: mozilla1.2alpha → Future
Assignee | ||
Comment 3•22 years ago
|
||
Comment 4•22 years ago
|
||
(worksforme on windows as well unless I'm misunderstanding the testcase)
Comment 5•22 years ago
|
||
i tested on the following platform/builds :-
1. linux - branch build as well as trunk build of 2002-10-01
2. win2000 - trunk build 2002-09-30
i am able to reproduce the problem.
steps to reproduce :
--------------------
1. open the testcase attachment 99617 [details] on a maximized window
actual -- body:after content is appended to the actual body part (correct behaviuor)
2. now resize the window so that the content of the ":after" rule does not fit
on one line anymore
3. reload the page
actual -- body:after content is prepended to the actual body part
expected -- body:after content should be appended to the actual body part
adding keyword 'testcase'
Keywords: testcase
Comment 6•21 years ago
|
||
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031011
Assignee | ||
Comment 7•21 years ago
|
||
Seems to have been fixed between 1.4a and 1.4b.
Assignee | ||
Comment 8•21 years ago
|
||
Was fixed between 2003-04-21-12-trunk and 2003-04-21-22-trunk.
Assignee | ||
Comment 9•21 years ago
|
||
I suspect this was fixed by the checkin for bug 145425.
Assignee | ||
Comment 10•21 years ago
|
||
bz, do you think http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=bzbarsky%25mit.edu&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2003-04-21+16%3A04&maxdate=2003-04-21+16%3A08&cvsroot=%2Fcvsroot would have fixed this?
Assignee | ||
Comment 11•21 years ago
|
||
I think it did (based on the addition of IsGeneratedContentFor). We were probably thinking the :after content was :before content.
Comment 12•21 years ago
|
||
Yeah, maybe.... I've spent some time thinking about this, and I can't quite figure out what scenario with the old code would have produced this bug (ie what the order of events would have to be).... so I can't say for sure. :(
You need to log in
before you can comment on or make changes to this bug.
Description
•