If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

CSS pseudo-element :after for body tag displayed incorrectly on first load if content spans multiple lines

RESOLVED FIXED in Future

Status

()

Core
CSS Parsing and Computation
P2
major
RESOLVED FIXED
16 years ago
14 years ago

People

(Reporter: Daren, Assigned: dbaron)

Tracking

({testcase})

Trunk
Future
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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

16 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → mozilla1.1beta
(Assignee)

Updated

15 years ago
Target Milestone: mozilla1.1beta → mozilla1.2alpha
This pretty reliably WORKSFORME on a CVS tip build on a Linux-kernel OS.
(Assignee)

Comment 2

15 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

15 years ago
Created attachment 99617 [details]
reporter's testcase
(worksforme on windows as well unless I'm misunderstanding the testcase)

Comment 5

15 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

14 years ago
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031011
(Assignee)

Comment 7

14 years ago
Seems to have been fixed between 1.4a and 1.4b.
(Assignee)

Comment 8

14 years ago
Was fixed between 2003-04-21-12-trunk and 2003-04-21-22-trunk.
(Assignee)

Comment 9

14 years ago
I suspect this was fixed by the checkin for bug 145425.
(Assignee)

Comment 10

14 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

14 years ago
I think it did (based on the addition of IsGeneratedContentFor).  We were
probably thinking the :after content was :before content.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Depends on: 145425
Resolution: --- → FIXED
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.