Closed
Bug 71979
Opened 24 years ago
Closed 23 years ago
<br><hr> inside link displays additional hr upon each mouseover
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
RESOLVED
FIXED
mozilla0.9.7
People
(Reporter: bulbul, Assigned: kinmoz)
References
()
Details
(Keywords: css2, regression, testcase, Whiteboard: [Hixie-P2] (high profile: very bad user experience!) fixed on trunk)
Attachments
(5 files, 1 obsolete file)
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
dbaron
:
review+
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
When you have the following construct: <a href="">text<br><hr></a> an additional horizontal rule is displayed each time the link is moused over. (See test case for exact code.) You can observe this in a real web page at <http://www.advocate.com> in the right sidebar "news" column. I have created a test case, which i will attach momentarily. This is very bizarre.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 4•24 years ago
|
||
Confirmed platform: PC OS: Windows 98 Mozilla Build: 2001031204 Marking NEW.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
OS: Linux → All
Hardware: PC → All
Comment 5•24 years ago
|
||
Ian - Are we using :before or :after for BR or HR now, or is this just a related bug to the problem I'm remembering?
Comment 6•24 years ago
|
||
Reassigning to waterson and marking m0.9.1.
Assignee: karnaze → waterson
Target Milestone: --- → mozilla0.9.1
Comment 7•24 years ago
|
||
We use :before and :after for <hr> elements in quirks mode. My patch for the HR/BR bug would remove this (and use :before for <br> elements). I would say this is a major bug, not minor at all! :-O This is almost certainly a dup of bug 69398.
QA Contact: petersen → ian
Whiteboard: [Hixie-P2] (high profile: very bad user experience!)
Updated•24 years ago
|
Status: NEW → ASSIGNED
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 10•24 years ago
|
||
Comments from dupe: This is caused by "<br> <hr>" inside <a>. Whitespace between the tags is necessary to reproduce it. It is quirks mode only. Another testcase: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=37795
Comment 13•24 years ago
|
||
Sigh, yet one more reason to fix 38370. This doesn't appear in standard mode. I'm not going to try to wallpaper over this one, and will just mark it dependent on that bug.
Depends on: 38370
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → mozilla1.0
Comment 14•24 years ago
|
||
with build 2001070108 win32 trunk I no longer see the bug in the testcase.
Comment 15•24 years ago
|
||
Okay, I don't see the bug anymore because mozilla nolonger apply :before{content: "\A";} or :after{content: "\A";} to hr and br. When I do, the bug appears. I'll post a testcase.
Comment 16•24 years ago
|
||
Comment 17•24 years ago
|
||
Comment 18•24 years ago
|
||
Assignee | ||
Comment 22•23 years ago
|
||
I have a fix in bug 96455 that fixes the problem for HR. It should work for the BR case also, but I'm seeing what I think is a bug where asking for the PrimaryFrame for a BR with :before and :after content, returns the :before frame instead of the nsBRFrame. This results in just the :before frame being removed from the frame tree, instead of all three frames (:before, nsBRFrame, and :after frame) being removed ... so in the testcases above, you end up with multiple :after frames for the br, as you hover in and out of the div.
Comment 23•23 years ago
|
||
This problem exists on my system (galeon 0.12.4 gecko 20011019). It pops up in malformed directory indexes sometimes -- <hr> in link because someone misplaced an </a> tag.
Assignee | ||
Comment 24•23 years ago
|
||
I have a fix for the problem where GetPrimaryFrame() is returning the :before frame, instead of the nsBRFrame for br nodes. That fix in combination with the fix for bug 96455, seems to fix all the test cases attatched to this bug. I'll take this off of waterson's plate, and try to get them both in for 0.9.7.
Assignee: waterson → kin
Status: ASSIGNED → NEW
Priority: -- → P3
Target Milestone: mozilla1.0 → mozilla0.9.7
Assignee | ||
Comment 25•23 years ago
|
||
The fix for bug 96455 has been checked into the trunk. Here's the patch that fixes the remaining problem with GetPrimaryFrameFor() not returning the correct frame when a BR has :before pseudo content. Once this patch goes in, all the test cases in this bug should work, and we can close out this bug.
Whiteboard: [Hixie-P2] (high profile: very bad user experience!) → [Hixie-P2] (high profile: very bad user experience!) FIX IN HAND, need r= and sr=
Attachment #57999 -
Flags: superreview+
Whiteboard: [Hixie-P2] (high profile: very bad user experience!) FIX IN HAND, need r= and sr= → [Hixie-P2] (high profile: very bad user experience!) FIX IN HAND, need r=
Comment 27•23 years ago
|
||
Hmmm. You never use |nextSiblingContent|. Did you mean to use it instead of |aContent|?
Comment 28•23 years ago
|
||
Comment on attachment 57999 [details] [diff] [review] Patch Rev 1 (Return the correct PrimaryFrame for a BR with :before) r=dbaron if you fix the text to use nextSiblingContent instead of kidContent.get(). (There's no need to use .get() anymore for ==.)
Attachment #57999 -
Flags: review+
Assignee | ||
Comment 29•23 years ago
|
||
Good catch dbaron ... I meant to use that. For the new patch I just changed: + if (kidContent.get() == aContent && to: + if (nextSiblingContent.get() == aContent &&
Attachment #57999 -
Attachment is obsolete: true
Comment 30•23 years ago
|
||
Comment on attachment 58573 [details] [diff] [review] Patch Rev 1.1 (Address dbaron's nextSiblingContent catch) r=dbaron
Attachment #58573 -
Flags: review+
Attachment #58573 -
Flags: superreview+
Whiteboard: [Hixie-P2] (high profile: very bad user experience!) FIX IN HAND, need r= → [Hixie-P2] (high profile: very bad user experience!) ready for checkin
Assignee | ||
Comment 31•23 years ago
|
||
Fix checked into trunk: mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp revision 1.657
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: [Hixie-P2] (high profile: very bad user experience!) ready for checkin → [Hixie-P2] (high profile: very bad user experience!) fixed on trunk
Comment 32•23 years ago
|
||
dont know if this is the same problem as exhibited in bug 62556, when clicking on scrollbars causes width of tables to resize and move sideways..
You need to log in
before you can comment on or make changes to this bug.
Description
•