Closed
Bug 460012
Opened 16 years ago
Closed 16 years ago
Firefox 3.1b1 :before and :after wackiness
Categories
(Core :: CSS Parsing and Computation, defect, P2)
Core
CSS Parsing and Computation
Tracking
()
VERIFIED
FIXED
mozilla1.9.1b3
People
(Reporter: kroc, Assigned: roc)
References
()
Details
(Keywords: regression, testcase, verified1.9.1)
Attachments
(3 files, 1 obsolete file)
(deleted),
text/html; charset=UTF-8
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1
Firstly, yes I assume that because 3.1 is beta, this may not need to be reported.
I'm experiencing some broken behaviour with :before and :after.
Reproducible: Always
Steps to Reproduce:
1. Visit camendesign.com
2. Mouse over:
i. The tag list on the left
ii. The blue tags on the right
3. Watch results (the bullet points and count numbers for the tags are done with :after and :before)
Actual Results:
* The tags spasm about
* For the tags on the right, if you mouse enter from above, they show the correct arrow - if you mouse enter from the side, the :before appears after!
Expected Results:
See website in Firefox 3.0,
When you mouse over a tag, the bullet changes to an arrow. There is no movement of the text
Comment 1•16 years ago
|
||
This regressed bewteen:
Gecko/20080817040141 Minefield/3.1a2pre (ok)
and
Gecko/20080818032051 Minefield/3.1a2pre (fails)
Likely from bug 238072
Blocks: 238072
Status: UNCONFIRMED → NEW
Component: General → Style System (CSS)
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → style-system
Version: unspecified → Trunk
Comment 2•16 years ago
|
||
Comment 3•16 years ago
|
||
I just readded the text alignment that's necessary to show the text movement.
Attachment #343217 -
Attachment is obsolete: true
Updated•16 years ago
|
Flags: blocking1.9.1?
Updated•16 years ago
|
OS: Mac OS X → All
Hardware: Macintosh → All
Comment 4•16 years ago
|
||
(In reply to comment #0)
> Firstly, yes I assume that because 3.1 is beta, this may not need to be
> reported.
> I'm experiencing some broken behaviour with :before and :after.
No, I think you're the first person who reported this, which means we might not otherwise have known it was a problem. (If we did know about it, it would be in Bugzilla somewhere.)
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → roc
Updated•16 years ago
|
Keywords: regression,
testcase
Assignee | ||
Comment 5•16 years ago
|
||
Click on the green-bordered body. The X should change to a Y and keep its border, but instead it stays X and loses the border. If you zoom, it changes to a Y with a red border, indicating that rebuilding the style data and reflowing fixes the bug.
Assignee | ||
Comment 6•16 years ago
|
||
Mmm ... we seem to be getting a RecreateFramesForContent call on the anonymous XML :after node! That's not going to work.
Assignee | ||
Comment 7•16 years ago
|
||
When we recreate frames for a generated content node, we should reframe the nearest non-generated-content ancestor.
Attachment #346418 -
Flags: superreview?(bzbarsky)
Attachment #346418 -
Flags: review?(bzbarsky)
Assignee | ||
Updated•16 years ago
|
Whiteboard: [needs review]
Updated•16 years ago
|
Attachment #346418 -
Flags: superreview?(bzbarsky)
Attachment #346418 -
Flags: superreview+
Attachment #346418 -
Flags: review?(bzbarsky)
Attachment #346418 -
Flags: review+
Comment 8•16 years ago
|
||
Comment on attachment 346418 [details] [diff] [review]
fix
Looks reasonable. I assume this reframe is coming from ReResolveStyleContext followed by processing the restyle list?
Assignee | ||
Comment 9•16 years ago
|
||
Yep.
Assignee | ||
Comment 10•16 years ago
|
||
Er, maybe I'm not sure what you meant. We get this reframe directly from restyling; the change of 'content' on the :after node seems to directly turn into a framechange hint for the anonymous XML container for the :after content.
Assignee | ||
Updated•16 years ago
|
Whiteboard: [needs review] → [needs landing]
Assignee | ||
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Comment 11•16 years ago
|
||
Landed on mozilla-central (and thus also on mozilla-1.9.1):
http://hg.mozilla.org/mozilla-central/rev/50eecdcfa91f
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla1.9.1b3
Assignee | ||
Updated•16 years ago
|
Flags: in-testsuite+
Reporter | ||
Comment 12•16 years ago
|
||
This is still present in Firefox 3.1 Beta 2. (See camendesign.com)
Did this fix not make it into Beta 2?
If it did, then the bug should be re-opened. The lists are still twitching about on mouse over, and now the :hover:before/after isn't being applied.
Assignee | ||
Comment 13•16 years ago
|
||
This bug is fixed on trunk, i.e. in nightly builds. Beta2 is a couple of weeks old already. The fix will be in the next beta.
Updated•16 years ago
|
Keywords: fixed1.9.1
Comment 14•16 years ago
|
||
verified FIXED on builds:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090407 Shiretoko/3.5b4pre ID:20090407031108
and
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090406 Minefield/3.6a1pre ID:20090406035346
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in
before you can comment on or make changes to this bug.
Description
•