Closed Bug 659278 (CVE-2011-3649) Opened 13 years ago Closed 13 years ago

[Azure] canvas.drawWindow() renders content from different windows

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla8
Tracking Flags:
Tracking Status
firefox8 - ---
firefox9 - fixed
firefox10 --- verified
firefox11 --- verified
status1.9.2 --- unaffected

People

(Reporter: ted, Assigned: bas.schouten)

References

Details

(Whiteboard: [sg:high][qa!])

Attachments

(1 file)

screenshot
1.09 MB, image/png
Details
Attached image screenshot — 
See attached screenshot. I don't have any useful info to offer about how I got into this situation, but I can poke at the browser if you'd like.

Clicking on one of the tabs in the Panorama view and then returning to Panorama causes the tab to change to a correct thumbnail.
Did it happen after you start Fx and then went into Panorama?
I had been running Fx for a while, but that may have been the first time I entered Panorama.
i'm seeing this too. What could be of relevance is that I'm running FF with browser.sessionstore.max_concurrent_tabs = 0, although the issue does not affect not-yet-loaded tabs (they're just blank), so maybe not...
I have this problem too. I first noticed it on May 20, running Nightly on 64 bit windows 7.

When I go to panorama view, the tab I'd been looking at always gets a proper thumbnail, at least at first.

Some other thumbnails are often correct, but tend to go wrong when I resize the tab groups such that the thumbnails' sizes changes too. During the resize, a bunch of tabs' thumbnails will all change to one tab's thumbnail. If I keep resizing, usually that same bunch of tabs will switch, together, to a different tab's thumbnail. I haven't recognized a pattern for which tab's thumbnail is used.

I tried to reproduce in in safe mode. I haven't seen it go wrong while in safe mode, but it will show the wrong thumbnails for inactive tab groups, if they were already wrong before I restarted into safe mode. In safe mode, the thumbnails get fixed during normal usage, resizing, etc.

Back in not-so-safe mode, I disabled all my extensions, and still see the same bad thumbnails.
bugspam
No longer blocks: 653099
bugspam
Blocks: 660175
I just noticed something weird - the thumbnails always seem to get corrected when they are more than 148 pixels wide.
This may have been fixed, recently. I only just noticed that I haven't been able to reproduce it with today's nightly (build id http://hg.mozilla.org/mozilla-central/rev/c72829d9cb2b).
Just tested with Nightly and indeed this is fixed. Hopefully this fix comes Aurora very soon?
It's still not fixed in Aurora as of June 22.
It's back in nightly, too, if it was ever truly fixed (I wasn't seeing it, for a while).
http://hg.mozilla.org/mozilla-central/rev/fc7d76664c79
I can confirm this too. It's back:(


Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110626 Firefox/7.0a1 ID:20110626030756
Okey, This bug has been fixed todays Aurora build. 
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110628 Firefox/6.0a2

Still broken on Nightly. 
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110628 Firefox/7.0a1 ID:20110628030753
After merge this bug is back on Aurora:( 

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a2) Gecko/20110707 Firefox/7.0a2
bugspam

(Fx7 was branched, removing open bugs from Fx7 meta bug, we won't create new meta bugs for upcoming Fx versions)
No longer blocks: 660175
This is standard fare for me also (running Aurora). Makes the thumbnails rather irrelevant, since often the same thumbnail will be stretched across 6 or more tabs, so it's impossible to know which one you actually want from the thumbnail.
Can anyone reproduce this with a current nightly?
Oops, sorry, of course that's noted in bug 676551...
I went back trying to find a build where this starts -
no bug in this one:
    20110518030622 http://hg.mozilla.org/mozilla-central/rev/dec16a247230
can reproduce with this one:
    20110519030627 http://hg.mozilla.org/mozilla-central/rev/caba046161e5 

I guess we don't have hourlies going back that far, do we?
This bug was on the beta when I just installed it now (in addition to aurora and nightly, as people have said). I've been able to reproduce on 32 & 64 bit windows builds, but not on my Mac Nightly.
This bug had also gone away for a while in June, so I tested a bunch of builds to see which I could use to reproduce the error:

bug present:
    20110610030736 http://hg.mozilla.org/mozilla-central/rev/1619d8fc6416
bug went away:
    20110611030737 http://hg.mozilla.org/mozilla-central/rev/dc8d154f3710
. . .
    20110625030743 http://hg.mozilla.org/mozilla-central/rev/ce10fd5d82c6
bug returned:
    20110626030756 http://hg.mozilla.org/mozilla-central/rev/fc7d76664c79

I did that testing with win32 nightly.
Thanks very much for that information! There are indeed some basic Panorama changes in the given commit ranges. Will investigate further.
(In reply to Jack Eidsness from comment #23)
> I did that testing with win32 nightly.

Which steps did you use to reproduce this bug? I couldn't reproduce it so far with the nightly versions you mentioned above...
Well, there is some unknown component to it, because I haven't been able to do it with a fresh profile, but I can't make it go away by disabling add-ons or plugins, either. But for me, on this profile, it's quite easy. I just start the browser (usually I already have a bunch of open tabs, but I may have to open some if I do not).  I go to the panorama view, and re-size a tab group until the thumbnails are fairly small ( < 148 pixels wide ) and that's when they will all change to the same thumbnail.
Correction: I just did another set of quick tests and I can see the bug happening with a fresh profile, but not in safe mode (fresh profile or otherwise).
When I was talking about "disabling add-ons or plugins" I was referring specifically to eliminating things from my profile during normal use in not-so-safe mode.

I just ran through all the 5 safe-mode options, after backing up my profile,

disable all add-ons
reset toolbars and controls
delete all bookmarks except for backups
reset all user preferences to nightly defaults
restore default search engines

and none of those work around the bug, but actually continuing in safe mode does.
After doing a diff between about:support in and out of safe mode, I saw direct2d and directwrite are off in safe mode and "GPU accelerated windows" goes from "1/1 direct3d10" to "0/1" in safe mode.
So as an experiment, I set gfx.direct2d.disabled to true, and the bug went away in normal mode. If I flip that back to false, the bug doesn't happen again until I restart the browser.

Here is my about:support Graphics section, from when the bug was happening:

  Graphics

        Adapter Description
        ATI Radeon HD 4800 Series

        Vendor ID
        1002

        Device ID
        9442

        Adapter RAM
        1024

        Adapter Drivers
        aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64

        Driver Version
        8.850.0.0

        Driver Date
        4-19-2011

        Adapter RAM (GPU #2)
        Unknown

        Adapter Drivers (GPU #2)
        Unknown

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7601.17563)

        ClearType Parameters
        DISPLAY1 [ Gamma: 2200 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 50 ] DISPLAY2 [ Gamma: 2200 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 200 ] DISPLAY4 [ Gamma: 2200 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 100 ] DISPLAY5 [ Gamma: 2200 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 50 ]

        WebGL Renderer
        Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.686)

        GPU Accelerated Windows
        1/1 Direct3D 10
The same is true for me; setting Direct2d.disabled to true corrected my thumbnail behaviour.
(In reply to Jack Eidsness from comment #29)
> After doing a diff between about:support in and out of safe mode, I saw
> direct2d and directwrite are off in safe mode and "GPU accelerated windows"
> goes from "1/1 direct3d10" to "0/1" in safe mode.
> So as an experiment, I set gfx.direct2d.disabled to true, and the bug went
> away in normal mode. If I flip that back to false, the bug doesn't happen
> again until I restart the browser.

That is indeed very helpful. Do you have any errors/messages in the error console when experiencing this issue?
No, I didn't encounter anything on the error console either when entering/exiting Panorama, resizing groups with duplicated thumbnails or moving tabs between groups (which, incidentally, temporarily fixes their thumbnail).
I have this bug as well, using FF 7 beta. Disabling direct2d fixes the problem (although firefox crashes, when I close it after I disable direct2d). My graphic card information is as follows:

  Graphics

        Adapter Description
        NVIDIA Quadro FX 580

        Vendor ID
        10de

        Device ID
        0659

        Adapter RAM
        512

        Adapter Drivers
        nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um

        Driver Version
        8.17.12.7589

        Driver Date
        8-5-2011

        Direct2D Enabled
        false

        DirectWrite Enabled
        false (6.1.7601.17563)

        ClearType Parameters
        ClearType parameters not found

        WebGL Renderer
        Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.686)

        GPU Accelerated Windows
        1/1 Direct3D 9
This issue is reproducible for me also on Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110905 Firefox/9.0a1

If I minimize the tab group, all the tabs are the same like in the attachment from the description.
I can also reproduce this bug in Firefox Beta 7, on Windows 7.
BuildID:  http://hg.mozilla.org/releases/mozilla-beta/rev/d70ed894123a

This is a very annoying bug from a user's perspective and is highly visible.  My personal opinion, from a user's standpoint, is that this needs prompt attention and should not ship in Firefox 7 Final.

I understand that opinions should stay out of bug reports, but felt the need to express mine here.

Thank you.
Pushlog of Comment 22: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dec16a247230&tochange=caba046161e5

=> Bug 620216 "sounds" reasonable as Cause since this seems to be happening on D2D Usage only per previous Comments, no?
Version: unspecified → Trunk
What is the timing expectation for correcting this bug?  As I mentioned in comment 35, it is highly visible and very annoying from a user's perspective.  Something so forward-facing, IMHO, should get a fairly high priority.
I think it's too late to get this in for Firefox 7. Can we track this for fixing in either Firefox 8 or 9?
tracking-firefox8: --- → ?
tracking-firefox9: --- → ?
Whiteboard: [qa+]
Based on comment 29, it looks like a graphics bug.
We're not tracking this for a particular version of Firefox. If there is a reviewed patch feel free to nominate to land and we will make a decision on the risk vs reward
tracking-firefox8: ? → -
tracking-firefox9: ? → -
As reported in bug 690602 the problem disappears by setting "gfx.canvas.azure.enabled" to "false".
Component: Panorama → Graphics
Product: Firefox → Core
QA Contact: panorama → thebes
Summary: Tabs in panorama using the same thumbnail → [Azure] canvas.drawWindow() renders content from different windows
Interesting, this bug was filed before Azure was in the tree. So I'm not sure how the original bug is related to the current bug we're tracking and such.
(In reply to Bas Schouten (:bas) from comment #44)
> Interesting, this bug was filed before Azure was in the tree. So I'm not
> sure how the original bug is related to the current bug we're tracking and
> such.

The bug also disappears by flipping the pref "gfx.direct2d.disabled". So maybe it's not an Azure but a D2D issue?
(In reply to Tim Taubert [:ttaubert] from comment #45)
> (In reply to Bas Schouten (:bas) from comment #44)
> > Interesting, this bug was filed before Azure was in the tree. So I'm not
> > sure how the original bug is related to the current bug we're tracking and
> > such.
> 
> The bug also disappears by flipping the pref "gfx.direct2d.disabled". So
> maybe it's not an Azure but a D2D issue?

That will actually also disable Azure. So it sounds like the last report does point at Azure.
(In reply to Bas Schouten (:bas) from comment #44)
> Interesting, this bug was filed before Azure was in the tree. So I'm not
> sure how the original bug is related to the current bug we're tracking and
> such.

Comment 9 and comment 10 indicate that this was fixed at some point and reoccurred, so it may be that the new instance of this bug has a different root cause than the original.
(In reply to Ted Mielczarek [:ted, :luser] from comment #47)
> (In reply to Bas Schouten (:bas) from comment #44)
> > Interesting, this bug was filed before Azure was in the tree. So I'm not
> > sure how the original bug is related to the current bug we're tracking and
> > such.
> 
> Comment 9 and comment 10 indicate that this was fixed at some point and
> reoccurred, so it may be that the new instance of this bug has a different
> root cause than the original.

Ah, this is pretty interesting, considering I probably copy-pasted the old canvas implementation to Azure when this bug existed. If we know what fixed it in the old canvas implementation that fix probably simply needs to be duplicated to Azure! I'll look into this.
(In reply to Ted Mielczarek [:ted, :luser] from comment #47)
> Comment 9 and comment 10 indicate that this was fixed at some point and
> reoccurred, so it may be that the new instance of this bug has a different
> root cause than the original.

According to the revisions mentioned in comment #22 and comment #23 those are the regression ranges that introduced the bug (again):

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dec16a247230&tochange=caba046161e5
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ce10fd5d82c6&tochange=fc7d76664c79
(In reply to Bas Schouten (:bas) from comment #48)
> Ah, this is pretty interesting, considering I probably copy-pasted the old
> canvas implementation to Azure when this bug existed. If we know what fixed
> it in the old canvas implementation that fix probably simply needs to be
> duplicated to Azure! I'll look into this.

This range should probably contain the patch that fixes this bug:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1619d8fc6416&tochange=dc8d154f3710
https://hg.mozilla.org/mozilla-central/rev/87406ae57a1b seems suspect as the fix. However we should have similar logic in Azure, investigating.
Assignee: nobody → bas.schouten
Status: NEW → ASSIGNED
Group: core-security
This is a duplicate of an existing security bug. I'm working on a fix.
Depends on: CVE-2011-2986
I just noticed that I couldn't reproduce this bad panorama behavior within today's nightly, and the azure & direct2d options are normal. Thank You :)
Working here too!

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111006 Firefox/10.0a1 ID:20111006030949
The Bug 655836 fix fixed this issue.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Blocks: 626527
Alias: CVE-2011-3649
Group: core-security
status1.9.2: --- → unaffected
status-firefox10: --- → fixed
status-firefox11: --- → fixed
status-firefox9: --- → fixed
Whiteboard: [qa+] → [sg:high][qa+]
Target Milestone: --- → mozilla8
Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0
Mozilla/5.0 (Windows NT 6.1; rv:11.0a2) Gecko/20120124 Firefox/11.0a2

Verified on Firefox 10 Beta 6 and Firefox Aurora (Firefox 11) in Windows 7 using the steps to repro this issue from duplicated bugs:

1. Create two groups.
2. Open at least 10 tabs in one of the group.
3. Switch to Panorama.
4. Resize the larger tab group by minimizing at maximum (before a stack group is created)

There are no duplicate thumbnails anymore.
Status: RESOLVED → VERIFIED
status-firefox10: fixed → verified
status-firefox11: fixed → verified
Whiteboard: [sg:high][qa+] → [sg:high][qa!]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: