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)
Tracking
()
VERIFIED
FIXED
mozilla8
People
(Reporter: ted, Assigned: bas.schouten)
References
Details
(Whiteboard: [sg:high][qa!])
Attachments
(1 file)
(deleted),
image/png
|
Details |
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.
Comment 1•13 years ago
|
||
Did it happen after you start Fx and then went into Panorama?
Reporter | ||
Comment 2•13 years ago
|
||
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...
Comment 4•13 years ago
|
||
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.
Comment 8•13 years ago
|
||
I just noticed something weird - the thumbnails always seem to get corrected when they are more than 148 pixels wide.
Comment 9•13 years ago
|
||
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).
Comment 10•13 years ago
|
||
Just tested with Nightly and indeed this is fixed. Hopefully this fix comes Aurora very soon?
Comment 11•13 years ago
|
||
It's still not fixed in Aurora as of June 22.
Comment 12•13 years ago
|
||
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
Comment 13•13 years ago
|
||
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
Comment 14•13 years ago
|
||
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
Comment 15•13 years ago
|
||
After merge this bug is back on Aurora:(
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a2) Gecko/20110707 Firefox/7.0a2
Comment 16•13 years ago
|
||
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
Comment 17•13 years ago
|
||
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.
Comment 19•13 years ago
|
||
Can anyone reproduce this with a current nightly?
Comment 20•13 years ago
|
||
Oops, sorry, of course that's noted in bug 676551...
Comment 22•13 years ago
|
||
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.
Comment 23•13 years ago
|
||
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.
Comment 24•13 years ago
|
||
Thanks very much for that information! There are indeed some basic Panorama changes in the given commit ranges. Will investigate further.
Comment 25•13 years ago
|
||
(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...
Comment 26•13 years ago
|
||
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.
Comment 27•13 years ago
|
||
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).
Comment 28•13 years ago
|
||
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.
Comment 29•13 years ago
|
||
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
Comment 30•13 years ago
|
||
The same is true for me; setting Direct2d.disabled to true corrected my thumbnail behaviour.
Comment 31•13 years ago
|
||
(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?
Comment 32•13 years ago
|
||
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).
Comment 33•13 years ago
|
||
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
Comment 34•13 years ago
|
||
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.
Comment 35•13 years ago
|
||
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.
Comment 36•13 years ago
|
||
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
Comment 37•13 years ago
|
||
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.
Comment 38•13 years ago
|
||
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:
--- → ?
Comment 39•13 years ago
|
||
Based on comment 29, it looks like a graphics bug.
Comment 40•13 years ago
|
||
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
Comment 42•13 years ago
|
||
As reported in bug 690602 the problem disappears by setting "gfx.canvas.azure.enabled" to "false".
Updated•13 years ago
|
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
Assignee | ||
Comment 44•13 years ago
|
||
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 45•13 years ago
|
||
(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?
Assignee | ||
Comment 46•13 years ago
|
||
(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.
Reporter | ||
Comment 47•13 years ago
|
||
(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.
Assignee | ||
Comment 48•13 years ago
|
||
(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.
Comment 49•13 years ago
|
||
(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
Comment 50•13 years ago
|
||
(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
Assignee | ||
Comment 51•13 years ago
|
||
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
Assignee | ||
Updated•13 years ago
|
Group: core-security
Assignee | ||
Comment 52•13 years ago
|
||
This is a duplicate of an existing security bug. I'm working on a fix.
Depends on: CVE-2011-2986
Comment 53•13 years ago
|
||
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 :)
Comment 54•13 years ago
|
||
Working here too!
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111006 Firefox/10.0a1 ID:20111006030949
Assignee | ||
Comment 55•13 years ago
|
||
The Bug 655836 fix fixed this issue.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
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
Comment 59•13 years ago
|
||
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
Whiteboard: [sg:high][qa+] → [sg:high][qa!]
You need to log in
before you can comment on or make changes to this bug.
Description
•