Odd shadowing around newtab's sponsored panel

VERIFIED FIXED in Firefox 31

Status

()

defect
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Mardak, Assigned: emtwo)

Tracking

Trunk
Firefox 31
All
Windows 7
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(firefox31 verified)

Details

(Whiteboard: p=3 s=it-31c-30a-29b.2 [qa!])

Attachments

(1 attachment)

No description provided.
Flags: firefox-backlog?
Not sure what happened to my description...

Bug 975228 comment 41 item 4 mentions an odd shadowing on Windows and provides attachment 8401126 [details]
Duplicate of this bug: 991804
Another screenshot from bug 991804 attachment 8401435 [details].
I think the box-shadow on the panel may need to be set to 'none'.
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #4)
> I think the box-shadow on the panel may need to be set to 'none'.
Thanks. emtwo, can you take a look on your windows machine? I hope it's as simple as just opening a tab, clicking the panel and verifying in inspector that there's a box-shadow from somewhere.
Assignee: nobody → msamuel
Whiteboard: p=3
Blocks: tiles-dev
Depends on: 974745
No longer depends on: 975228
I've explored this a bit but didn't make much progress.

I've tried setting box-shadow to none on #sponsored-panel as well as making changes to toolkit/themes/windows/global/popup.css such as panel's border, margin, color. Any suggestions where else this could be coming from or how to debug it? Thanks! :jaws, :Mardak

Or maybe can pass this bug on to someone more familiar with the arrow panel? I don't think this bug is sponsored-panel specific as far as I can tell.
Flags: needinfo?(jaws)
enn/dao, have either of you run into this odd shadowing issue when implementing the animation?

emtwo, can you try applying bug 610545 to see if something magically gets fixed?
Is this a standard arrow panel or something custom?
Applying bug 610545 didn't fix the issue... but the animation is pretty cool!
Flags: firefox-backlog? → firefox-backlog+
Hey Neil, do you have any insight on this issue? :jaws and :mconley have looked without much progress as well and suspect it's something lower level. Thanks!
Flags: needinfo?(enndeakin)
We don't allow translucent windows in non-chrome docshells. We should probably change this to be based on the popup being in a privileged page or somesuch.
Flags: needinfo?(enndeakin)
OK, that's not quite correct. It's just the windows dropshadow (CS_DROPSHADOW) that is blocked in content shells. Actually there are two options, and we could do either or both:

1. Do what I suggested above. That would also fix the popup so that it wasn't constrained by the window border.
2. Just remove the check content shell check since you can just make transparent popups on other platforms anyway.
This patch implements option 2.

Transparent windows have been allowed since bug 451300 (although I think the patch for that bug wasn't correct).
Comment on attachment 8403499 [details] [diff] [review]
Allow drop shadows in content shell popups

Thanks very much for looking into this Neil and adding the patch! I verified that this fixes the issue on windows and doesn't seem to mess with anything on mac. I'm adding :tn for review here.
Attachment #8403499 - Flags: review?(tnikkel)
Attachment #8403499 - Flags: review?(tnikkel) → review+
(In reply to Neil Deakin from comment #14)
> Transparent windows have been allowed since bug 451300 (although I think the
> patch for that bug wasn't correct).

Don't we need xul to create transparent panels? And xul is not allowed in typical unprivileged content. So perhaps this got fixed by disabling xul?
Whiteboard: p=3 → p=3 s=it-31c-30a-29b.2
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/a8121fe54033
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 31
Whiteboard: p=3 s=it-31c-30a-29b.2 → p=3 s=it-31c-30a-29b.2 [qa?]
Florin, please assign this for verification in this iteration. I know it's late in the iteration so please needinfo me if testing cannot be completed before the weekend.
QA Contact: florin.mezei
Whiteboard: p=3 s=it-31c-30a-29b.2 [qa?] → p=3 s=it-31c-30a-29b.2 [qa+]
I'll work on this issue and update the results later today.
QA Contact: florin.mezei → cornel.ionce
I cannot verify this fix because the grid is no longer populated. For a clean profile, the newtab page is only having the first tile populated (First Run page) and the rest of them are empty.

It seems this started from yesterday's nightly (2014-04-10).

Any ideas what could have happened?
Flags: needinfo?(msamuel)
Flags: needinfo?(jaws)
Flags: needinfo?(edilee)
(In reply to Cornel Ionce [QA] from comment #21)
> I cannot verify this fix because the grid is no longer populated.
The list was temporarily removed for now, you can see it again by changing

browser.newtabpage.directorySource pref to..
chrome://global/content/directoryLinks.json
Flags: needinfo?(msamuel)
Flags: needinfo?(jaws)
Flags: needinfo?(edilee)
Thanks for your response.

By changing the pref mentioned in comment 22 I was able to confirm this fix using latest Nightly (build ID: 20140411030201) on Windows 7 and Windows 8.1
Status: RESOLVED → VERIFIED
Whiteboard: p=3 s=it-31c-30a-29b.2 [qa+] → p=3 s=it-31c-30a-29b.2 [qa!]
You need to log in before you can comment on or make changes to this bug.