Closed
Bug 328296
Opened 19 years ago
Closed 18 years ago
Obscured outlines are drawn (through things that are on top and not transparent)
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: jruderman, Assigned: roc)
References
()
Details
(Keywords: regression, testcase)
Attachments
(9 files)
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
MatsPalmgren_bugz
:
review+
MatsPalmgren_bugz
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
image/png
|
Details |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060219 Firefox/1.6a1
I first noticed this on Tinderbox: after clicking a star to see a "DHTML popup" message, I noticed that the star's outline was displayed on top of the message.
I think this a regression from the Frame Display Lists patch (bug 317375).
Reporter | ||
Comment 1•19 years ago
|
||
Comment 3•19 years ago
|
||
I think that's on purpose, see bug 317375, comment 82 and comment 83:
me:
"
http://wargers.org/317375_painting_bug_absolute.html
Painting bug with the patch. You should only see a small red and a small green
box. Resizing the window fixes it.
"
Roc:
"
(In reply to comment #82)
> http://wargers.org/317375_outline.htm
> I see that outline is now always at the top, I guess that's on purpose,
> right?
Yes, that is recommended by the spec.
"
Assignee | ||
Comment 4•19 years ago
|
||
Yes, I believe this is per spec.
Reporter | ||
Comment 5•19 years ago
|
||
Can you point me to the part of the spec that says that outlines should be on top of everything? I find it hard to believe because it seems weird and breaks any page that does stuff the way Tinderbox does.
Comment 6•19 years ago
|
||
Please. People. For the love of all things sweet and holy. Make your testcases trigger strict mode!
It's not hard, just include "<!DOCTYPE HTML>" at the top of the page.
Comment 7•19 years ago
|
||
The answer to your question, btw, is CSS 2.1 Appendix E section 2 step 9.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 8•19 years ago
|
||
Hixie, do you know why the spec says that? It seems wrong and broken to me.
Comment 9•19 years ago
|
||
*** Bug 341069 has been marked as a duplicate of this bug. ***
Comment 10•18 years ago
|
||
Comment 11•18 years ago
|
||
I agree with Jesse, the new behavior seems wrong and broken.
CSS 2.1 specifies two alternatives for outline rendering,
either at the end of step 7 (before positioned elements)
or at step 10 (after positioned elements).
http://www.w3.org/TR/CSS21/zindex.html#q2
Firefox 1.5/2, Opera 9 and Webkit have compatible implementations (step 7).
IE7 does not implement outline as far as I can tell.
CSS 2.1 recommends step 10 over earlier steps (without motivating why).
The CSS 2.1 abstract says:
<q>But most of all CSS 2.1 represents a "snapshot" of CSS usage:
it consists of all CSS features that are implemented interoperably
at the date of publication of the Recommendation.</q>
Recommending step 10 is clearly in conflict with the goal set out
in the abstract. It should recommend step 7 (if anything) because
that's what been interoperably implemented.
Assignee | ||
Comment 12•18 years ago
|
||
IE most certainly does implement outline. I doubt they've removed it from IE7.
Changing our behaviour is probably not hard but I won't change it unless Ian agrees the spec should be changed.
Comment 13•18 years ago
|
||
The primary use case for 'outline' is indicating focus. If one alternative is good for focus indication and another is good for some other mysterious use of 'outline', we should choose the first. For indicating focus, I think drawing visible outlines at the position of covered elements is better.
Reporter | ||
Comment 14•18 years ago
|
||
When the focused element is covered, it's usually because the site wants you to see what's on top. (At least, that's true in the Tinderbox example.)
Comment 15•18 years ago
|
||
(In reply to comment #12)
> IE most certainly does implement outline. I doubt they've removed it from IE7.
I tested again several examples in IE7 on Vista and XPSP2 and I couldn't
find any example that worked. I even tried with vendor prefix.
All the CSS compatibility charts I found agree with me:
http://www.webdevout.net/browser-support#css
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(CSS)#Properties
http://www.quirksmode.org/css/contents.html
http://aptana.com/reference/api/CSSElements.index-fields.html
I understand that such charts are often wrong, incomplete and outdated,
but in this case they agree. There are some information that IE for
Mac (Tasman) has implemented 'outline', but that's not very interesting
since 99.99% (my estimate ;-) of all IE users are on Windows.
If you have an example that works in IE7 on Windows, please attach it.
Comment 16•18 years ago
|
||
(In reply to comment #13)
> The primary use case for 'outline' is indicating focus.
Sure, but the outline property itself is generic. I think it would be
a mistake for a UA vendor to implement it with only :focus in mind and
limit its usefulness for anything else.
(Have this been discussed on www-style? I searched the archives but
couldn't find anything.)
My guess is that web designers will regard this as a bug.
> For indicating focus, I think drawing
> visible outlines at the position of covered elements is better.
Why? Is this for some security concern, that focused form controls
should render its outline on top? If so, I think there are other
solutions to that problem.
Assignee | ||
Comment 17•18 years ago
|
||
(In reply to comment #15)
> (In reply to comment #12)
> > IE most certainly does implement outline. I doubt they've removed it from IE7.
>
> I tested again several examples in IE7 on Vista and XPSP2 and I couldn't
> find any example that worked.
I guess you're right. I assumed it supported 'outline' based on the outlines it draws for focused elements. But even if it doesn't support the property, the outlines it draws for focused elements are still relevant for compatibility.
Comment 18•18 years ago
|
||
IE7 on Vista draws the focus ring under the positioned block.
Assignee | ||
Comment 19•18 years ago
|
||
Fine. Get Hixie to explain why the spec says what it says.
Comment 20•18 years ago
|
||
(In reply to comment #16)
> My guess is that web designers will regard this as a bug.
So tell the designers that 'outline' is for focus outlines, and they should use borders instead.
Assignee | ||
Comment 22•18 years ago
|
||
Hixie suggests putting outlines in a new layer between layers 7 and 8. This is not quite what Mats said in comment #11. For example,
<div style="width:50px; height:50px; outline:50px solid green;"></div>
<div style="width:50px; height:50px; background:red;"></div>
Drawing outlines in step 7.3 would draw the background over the outline. Drawing outlines in a new layer between 7 and 8 would draw the outline over the background. Which alternative is the interoperable one?
I can change this fairly easily once we decide what the required behaviour is.
Flags: blocking1.9?
Assignee | ||
Updated•18 years ago
|
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 24•18 years ago
|
||
Steps to Reproduce:
1. Load the attached test case.
2. Press tab to activate the link.
3. The link border appears through the yellow div.
4. Click a blank part of the page to deactivate the link. Now, right click the link.
5. The border again appears through the yellow div.
Actual Results:
The link border is not masked through the higher z-index opaque div.
Expected Results:
The link border should be covered by the higher z-index opaque div, just like its text is.
Updated•18 years ago
|
Flags: blocking1.9? → blocking1.9+
Assignee | ||
Comment 25•18 years ago
|
||
The fix is actually really simple. I'm very proud of the display list architecture :-)
Mats, I'm throwing this review to you to keep it off David's plate and also because you raised the bug :-)
Assignee: nobody → roc
Status: REOPENED → ASSIGNED
Attachment #272131 -
Flags: superreview?(mats.palmgren)
Attachment #272131 -
Flags: review?(mats.palmgren)
Assignee | ||
Comment 26•18 years ago
|
||
OK it was originally Jesse's bug but you joined in :-)
Assignee | ||
Comment 27•18 years ago
|
||
Assignee | ||
Comment 28•18 years ago
|
||
This makes a nice reftest along with the previous testcase.
Comment 29•18 years ago
|
||
Here's a better testcase for testing IE7.
It looks like their themed <input> is actually changing its border color
rather than using an "outline". They do display a focus ring for
elements with tabindex="1" which is probably better for reverse
engineering purposes.
The case you mentioned in comment 22 is the green block.
It turns out that IE7 and Webkit does outlines in a step between 7/8
as you suspected (the green block's outline is above the cyan area).
Opera (9.20 on Vista) and Firefox 1.5/2 does it in 7.3.
The attached patch makes us compatible with IE7/Webkit AFAICT.
(well, IE7 paints its outline just inside the padding edge but
it looks compatible layering-wise)
Comment 30•18 years ago
|
||
Comment 31•18 years ago
|
||
Comment on attachment 272131 [details] [diff] [review]
fix
> // 5: floats
> resultList.AppendToTop(set.Floats());
>- // 6: general content
>+ // 7: general content
For completeness, I think you should include step 6 in the comments,
I guess it should say "6,7: general content"?
You might also want to change the order of these two lines:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsFrame.cpp&rev=3.741&root=/cvsroot&mark=1343-1344#1309
(not that it really matters, but they were listed in the same
order as the paint order below)
Attachment #272131 -
Flags: superreview?(mats.palmgren)
Attachment #272131 -
Flags: superreview+
Attachment #272131 -
Flags: review?(mats.palmgren)
Attachment #272131 -
Flags: review+
Comment 32•18 years ago
|
||
Have we posted to www-style about the discrepancy in UA behavior here?
Assignee | ||
Comment 33•18 years ago
|
||
Checked in patch and reftest.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 34•17 years ago
|
||
Adding "in-testsuite+" based on roc's comment 33.
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•