Image issues with apple.com

VERIFIED FIXED in Firefox 23

Status

()

Core
Layout
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Anthony Scotti, Assigned: roc)

Tracking

({regression})

23 Branch
mozilla24
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox21 unaffected, firefox22 unaffected, firefox23+ verified, firefox24+ verified)

Details

(URL)

Attachments

(8 attachments)

(Reporter)

Description

5 years ago
Created attachment 752928 [details]
issue.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20130522 Firefox/24.0 (Nightly/Aurora)
Build ID: 20130522031027

Steps to reproduce:

Go to Apple's OS X page at 'http://www.apple.com/osx/'


Actual results:

The images used for the scroll effect on top of the page are not being partially hidden.


Expected results:

It should be rendered the same as Firefox 21 and other browsers. This is issue is also in Firefox 23.

I do not know the underlying issue or if it's something that just relates to apple.com but there's differences between versions of Firefox rendering the page.

Please see images for more details.
(Reporter)

Comment 1

5 years ago
Created attachment 752929 [details]
Screenshot from Firefox 24
(Reporter)

Comment 2

5 years ago
Created attachment 752930 [details]
Screenshot from Firefox 23
(Reporter)

Comment 3

5 years ago
Created attachment 752931 [details]
Screenshot from Firefox 21
(Reporter)

Comment 4

5 years ago
Created attachment 752932 [details]
Screenshot from Chrome 27
(Reporter)

Comment 5

5 years ago
Created attachment 752934 [details]
Screenshot from Opera 12.15
(Reporter)

Updated

5 years ago
Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=55f9e3e3dae7&tochange=768af8d8fad4

Bug 841192 is in that range so I'm blaming it.
Blocks: 841192
Status: UNCONFIRMED → NEW
status-firefox21: --- → unaffected
status-firefox22: --- → unaffected
status-firefox23: --- → affected
status-firefox24: --- → affected
tracking-firefox23: --- → ?
tracking-firefox24: --- → ?
Component: Untriaged → Layout
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Hardware: x86 → All
Looks like this is over to you, roc.
Assignee: nobody → roc
tracking-firefox23: ? → +
tracking-firefox24: ? → +

Updated

5 years ago
Duplicate of this bug: 877271

Updated

5 years ago
OS: Mac OS X → All
Version: 24 Branch → 23 Branch

Comment 9

5 years ago
Created attachment 755567 [details]
reduced zip (open index.html)
It looks like overflow: hidden display: -moz-inline-stack frames would clip position: absolute descendants. But bug 841192 fixed this. Was this an intentional quirk of moz-inline-stack? It appears to have been noticed by someone at least. Not sure how common exploiting this is on the web.

The site has

  @-moz-document url-prefix() { 
    .gallery-view { position: absolute; }
  }

to apply the position absolute, and then also uses -moz-inline-stack. If you remove both of these gecko specific hacks the site renders fine. So it looks at though they added one gecko specific hack to work around a bug in another gecko specific hack in their site.
I don't think we should do anything to work around this.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
(In reply to Timothy Nikkel (:tn) from comment #10)
> It looks like overflow: hidden display: -moz-inline-stack frames would clip
> position: absolute descendants.

Note that the element additionally has position:relative set on it, which really should have the effect of clipping position:absolute descendants. display:-moz-inline-stack now seems to revert the effect.
OK, then we still have a bug to fix here.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to Markus Stange from comment #12)
> (In reply to Timothy Nikkel (:tn) from comment #10)
> > It looks like overflow: hidden display: -moz-inline-stack frames would clip
> > position: absolute descendants.
> 
> Note that the element additionally has position:relative set on it, which
> really should have the effect of clipping position:absolute descendants.
> display:-moz-inline-stack now seems to revert the effect.

Oh, the reduced testcase didn't have that. So I guess it is for a slightly different change.
The basic problem here is that relatively-positioned -moz-inline-stacks don't make abs-pos containers.
Bug 841192 altered this because prior to that fix, CSS 'overflow' clipping on -moz-inline-stacks would clip all the element's descendants, not just the ones for which it's the containing block. This is because nsStackFrame::BuildDisplayListForChildren forces all the display items for the element's descendants into the "Content" list, which is always clipped by nsXULScrollFrame's OverflowClip.

After 841192 was fixed, a XUL element behaves just like a normal element and only clips descendants for which it is the containing block. That, plus comment #15, means they don't clip abs-pos descendants.
I think the best approach here would be to restore the behaviour of -moz-inline-stack/-moz-stack so they clip all their descendants if overflow:hidden. Making them honour position:relative would also work but is probably too risky. The extra overhead can be almost entirely confined to XUL-related code.
Created attachment 762483 [details] [diff] [review]
fix

Adding code to handle something this obscure sucks in a way. A better thing to do might be to disable -moz-inline-stack and -moz-stack in Web content. However that's risky and we need a regression fix here.
Attachment #762483 - Flags: review?(matspal)
Comment on attachment 762483 [details] [diff] [review]
fix

layout/generic/nsGfxScrollFrame.h
>+  // True if we should clip all descendants, false if we should only clip
>+  // descendants for which we are the containing block
>+  bool mClipAllDescendants;

Please add :1 as the other bool members.

Nit: end the comment with a period.

Please also file a follow-up evangelism bug to make Apple.com stop
using -moz-* hacks like this since we intend to disable them for
web content (soon I hope).
Attachment #762483 - Flags: review?(matspal) → review+
(In reply to Mats Palmgren [:mats] from comment #19)
> Please also file a follow-up evangelism bug to make Apple.com stop
> using -moz-* hacks like this since we intend to disable them for
> web content (soon I hope).

We don't have to. Just ignoring the -moz-inline-stack rule makes the site work fine.
Comment on attachment 762483 [details] [diff] [review]
fix

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 841192
User impact if declined: broken rendering on apple.com page
Testing completed (on m-c, etc.): just landed
Risk to taking this patch (and alternatives if risky): very low risk, confined to users of XUL CSS feature
String or IDL/UUID changes made by this patch: none
Attachment #762483 - Flags: approval-mozilla-aurora?
Looks like this busted layout/reftests/bugs/411585-1.html.

Updated

5 years ago
Attachment #762483 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/db02f2b140d2
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
status-firefox24: affected → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla24

Updated

5 years ago
Depends on: 885009
Uplift nomination for Beta?
Flags: needinfo?(roc)
Comment on attachment 762483 [details] [diff] [review]
fix

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 841192
User impact if declined: slightly broken rendering on Apple.com
Testing completed (on m-c, etc.): landed on m-c for quite some time
Risk to taking this patch (and alternatives if risky): low risk. Only affects -moz-specific properties that aren't useful on the Web
String or IDL/UUID changes made by this patch: none
Attachment #762483 - Flags: approval-mozilla-beta?
Attachment #762483 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
https://hg.mozilla.org/releases/mozilla-beta/rev/0f8db9a9b1de
status-firefox23: affected → fixed
Flags: needinfo?(roc)
I confirm this is fixed on FF 23b5 on Mac OS 10.9:

Build ID: 20130711122148
status-firefox23: fixed → verified
(In reply to Mihai Morar, QA [:MarioMi] from comment #31)
> I confirm this is fixed on FF 23b5 on Mac OS 10.9:

Verified Fixed on Win 7 x64 and Ubuntu 13.04 x64 too on same FF23b5
Verified Fixed on FF 24b1 too.
BuildID: 20130806104538
Status: RESOLVED → VERIFIED
status-firefox24: fixed → verified
You need to log in before you can comment on or make changes to this bug.