Closed Bug 292116 Opened 20 years ago Closed 20 years ago

[FIXr]:before ending up before explicit children in some cases

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta3

People

(Reporter: ssb22, Assigned: bzbarsky)

Details

Attachments

(4 files)

Reporters first snippet, with some validation fixes
634 bytes, text/html
Details
Reporters second snippet, with some validation fixes
506 bytes, text/html
Details
Testcase
549 bytes, text/html
Details
Proposed fix
2.04 KB, patch
roc
: review+
roc
: superreview+
chofmann
: approval1.8b3+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 The following HTML snippet will reproduce some CSS rendering bugs. Make sure your browser window is smaller than the image. <html> <head> <style> A:hover { background-color: inherit; } A:before /* , a:link:hover:before */ { content: "["; } a:after { content: "]"; } img:before { content: "Image: "; } </style> </head> <body> <BR><A HREF="example"><IMG SRC="example" width=1200 height=1000></A> </body> </html> The bugs are: (1) the content from the "img:before" selector does not display, (2) mouse over the image causes the image to jump around (and if it's an image map then you never know quite what you're selecting). The bug can also be reproduced by putting the image in any column that is no wider than the image. The bug can be worked around by uncommenting the a:link:hover:before selector, or by removing any one of the lines in the stylesheet (i.e. ALL of the above lines are needed to reproduce it). However, if you uncomment the a:link:before selector then you hit another (related?) bug if you are also using :first-letter overrides. See the following HTML snippet: <html> <head> <style> body:first-letter, body:first-line { color: inherit; } a:hover:before { content: "->"; } </style> </head> <body> Mouse over this link, and it will disappear: <A HREF="example">link</A> </body> </html> As it suggests, if you mouse over that link, it will disappear. If you remove the body:first-line (but leave body:first-letter), the link will jump around instead of disappearing. If you remove body:first-letter then it behaves correctly (even if body:first-line is still there). It doesn't have to be "body". This works with any :first-letter and :first-line specification in conjunction with a:hover:before, as long as the link is in the element in question (although I can't ALWAYS reproduce it; however, the above snippet reproduces it every time). Reproducible: Always Steps to Reproduce: see above Actual Results: see above Expected Results: see above
I had to fix up his code by adding a dtd and a type for the style, as well as a title so that the validator would not complain about head closing before it should. Other changes involve setting the proper image size for the image I used.
Changes: Added dtd, encoding line, title, and style type. Made the url real (getfirefox), and checked the css with jigsaw. It worked. Addition: I checked the css on the first snippet, it too was valid.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050419 Firefox/1.0.4 I don't know exactly what I'm looking for in the first snippet, but at the start there's a [, then the image, then an ]. After I mouse over, the first [ disappears, the image moves up to take the gap, and now underneath the image is []. In the second snippet I do mouse over the link and it disappears. http://getfirefox.com goes to my statusbar and stays there. I am not a CSS expert, so I don't know if this is intended or not, but I am confirming this because it's happening as described (at least for the second snippet, I don't understand the first enough). Moving this bug to core, but I don't know which part of core it belongs in, so I'm just going to pick most likely and add qawanted to the keywords.
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
Keywords: qawanted
OS: Linux → All
Product: Mozilla Application Suite → Core
Version: unspecified → 1.7 Branch
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050426 Firefox/1.0+ Snippet 2 properly has a -> before it when i mouse over, and loses it when I move back. Snippet 1 retains the same [ IMAGE ] and then IMAGE [] when moused over.
> (1) the content from the "img:before" selector does not display, Correct. Generated content is not supported on replaced elements because it makes no sense there. > (2) mouse over the image causes the image to jump around That looks like a bug. I'll attach what I think is a minimal-ish testcase for it. I'd suggest filing separate bugs on the first-letter and first-line issues, after checking for duplicates.
Version: 1.7 Branch → Trunk
Attached file Testcase —
What I see here is that before the opacity change the frame model is: linebox span span:before linebox span img linebox span span:after After the opacity change, the model is: linebox span img linebox span span:before span:after which is clearly wrong. Having the image wide enough that three separate lines are involved is required here. What I can't understand is how we get there -- changing opacity should just do a view property sync, and we must be doing a reflow somewhere to rearrange the frame model like that. Toggling display instead of opacity does NOT show the bug....
Summary: Serious CSS rendering errors when I use my accessibility stylesheet → :before ending up before explicit children in some cases
Ah, changing opacity from 1 to something does still reframe...
Attached patch Proposed fix — — Splinter Review
Assignee: general → bzbarsky
Status: NEW → ASSIGNED
Attachment #185614 - Flags: superreview?(roc)
Attachment #185614 - Flags: review?(roc)
Priority: -- → P1
Summary: :before ending up before explicit children in some cases → [FIX]:before ending up before explicit children in some cases
Target Milestone: --- → mozilla1.8beta3
Attachment #185614 - Flags: superreview?(roc)
Attachment #185614 - Flags: superreview+
Attachment #185614 - Flags: review?(roc)
Attachment #185614 - Flags: review+
Comment on attachment 185614 [details] [diff] [review] Proposed fix Requesting 1.8b3 approval. This is a quite safe fix...
Attachment #185614 - Flags: approval1.8b3?
Keywords: qawanted
Summary: [FIX]:before ending up before explicit children in some cases → [FIXr]:before ending up before explicit children in some cases
Comment on attachment 185614 [details] [diff] [review] Proposed fix a=chofmann
Attachment #185614 - Flags: approval1.8b3? → approval1.8b3+
Fixed
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: