Closed Bug 863635 Opened 7 years ago Closed 7 years ago
Windows taskbar previews don't show the address bar
307.61 KB, image/jpeg
5.24 KB, patch
|Details | Diff | Splinter Review|
STR: 1) Set browser.taskbar.previews.enable = true (may need a restart?) 2) Open only a few tabs since we stop showing previews at some point 3) Mouse over the Firefox taskbar button 4) Mouse over the tab previews Expected result: The browser window should look like it does normally. The awesome bar should be shown. Actual result: The image of the browser window doesn't include the address bar. Last Good: 2012-09-20 First Bad: 2012-10-09 (intermediate nightlies have crashes upon hovering the taskbar preview) http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-09-20&enddate=2012-10-09 It seems like this is implemented using drawWindow on a 2D Canvas so I suspect the following landing in that range is related: http://hg.mozilla.org/mozilla-central/rev/a5cb3eecff37 Robert O'Callahan Bug 772726. Make nsCanvasRenderingContext2DAzure::DrawWindow use Azure content drawing if that's enabled. r=bas  http://hg.mozilla.org/mozilla-central/annotate/d1847d734c77/browser/modules/WindowsPreviewPerTab.jsm#l307
Requesting tracking-firefox24 since I suspect fixing this will fix bug 857649 which is targeted to ship in Firefox 24 and makes this problem more noticeable (see attachment 732903 [details]).
Roc: can you or someone else look into this? It seems to be an existing bug, but apparently will become more visible with Australis.
Nick Cameron can work on this.
Assignee: nobody → ncameron
Background: the first cause of the bug was that the clip set on the gfxContext in nsSVGClipPathFrame::ClipPaint was causing incorrect clipping. By painting the clip path rather than clipping with it I could see the path and transform were correct. I verified that there was no existing path or clip on the context. It turns out clipping was just broken. (This is called from nsSVGIntegrationUtils::PaintFramesWithEffects, btw. The awesome bar is wrapped in SVG effects, which causes an inactive layer (which means we paint with basic layers)). Clipping is broken because the gfxContext was wrapping a DrawTargetCairo, that is it was doing Azure content drawing using Cairo, which is not yet supported. I filed bug 877558 for some dodgy clipping in the Azure backend, I'm not sure whether that will fix this bug or not, I encountered it when trying to experiment with the clipping). One solution would be to always use a Thebes gfxContext in drawWindow, but that s undesirable because we will forget about it once Azure/Cairo content is done. Checking for Cairo surfaces in particular is a bad idea because Skia. So this patch is a little more complex than necessary, but I think it is future proof and adds functionality we might want elsewhere too.
Attachment #756400 - Flags: review?(bas) → review+
Try run: https://tbpl.mozilla.org/?tree=Try&rev=dfa40b556ca0 Linux is busted due to bug 878522.
Try push for Linux: https://tbpl.mozilla.org/?tree=Try&rev=32b04991140a
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Thanks! The addressbar now appears in taskbar previews on Windows 7.
Status: RESOLVED → VERIFIED
Verified fixed on Fx 24 beta 9, buildID 20130905180733. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
You need to log in before you can comment on or make changes to this bug.