No description provided.
Not sure what happened to my description... Bug 975228 comment 41 item 4 mentions an odd shadowing on Windows and provides attachment 8401126 [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
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.
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?
http://dxr.mozilla.org/mozilla-central/source/browser/base/content/newtab/newTab.xul#20 It's a panel with type arrow, not a custom binding
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!
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.
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?
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.
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?
(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
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
You need to log in before you can comment on or make changes to this bug.