863635 - Windows taskbar previews don't show the address bar

Status: VERIFIED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Matthew N. [:MattN]]

Attachment: Screenshot of missing addressbar in the tab preview

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[1] 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

[1] http://hg.mozilla.org/mozilla-central/annotate/d1847d734c77/browser/modules/WindowsPreviewPerTab.jsm#l307

Comment 1

[Matthew N. [:MattN]]

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]).

Comment 2

[Justin Dolske [:Dolske]]

Roc: can you or someone else look into this? It seems to be an existing bug, but apparently will become more visible with Australis.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Nick Cameron can work on this.

Comment 4

[Nick Cameron [:nrc]]

Attachment: fix by expressing support for Azure for a given DrawTarget

Comment 5

[Nick Cameron [:nrc]]

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.

Comment 6

[Nick Cameron [:nrc]]

Try run: https://tbpl.mozilla.org/?tree=Try&rev=dfa40b556ca0

Linux is busted due to bug 878522.

Comment 7

[Nick Cameron [:nrc]]

Try push for Linux: https://tbpl.mozilla.org/?tree=Try&rev=32b04991140a

Comment 8

[Nick Cameron [:nrc]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/486ec13ac5d7

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/486ec13ac5d7

Comment 10

[Matthew N. [:MattN]]

Thanks! The addressbar now appears in taskbar previews on Windows 7.

Comment 11

[Petruta Horea [:phorea], Desktop Test Engineering]

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