Closed Bug 556524 Opened 10 years ago Closed 3 years ago

Taskbar tab preview crashes [@ mozilla::widget::WindowHook::Lookup(unsigned int)] at SetVisible

Categories

(Core :: Widget: Win32, defect, P1, critical)

1.9.2 Branch
All
Windows 7
defect

Tracking

()

RESOLVED DUPLICATE of bug 1277167
Tracking Status
firefox48 --- wontfix
firefox49 --- wontfix
firefox-esr45 --- affected
blocking2.0 --- .x+
firefox50 --- wontfix
firefox51 --- fix-optional

People

(Reporter: mak, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: crash, regression, testcase-wanted, Whiteboard: [softblocker][tpi:+])

Crash Data

Attachments

(4 files)

0  	xul.dll  	mozilla::widget::WindowHook::Lookup  	 widget/src/windows/WindowHook.cpp:99
1 	xul.dll 	mozilla::widget::WindowHook::RemoveMonitor 	widget/src/windows/WindowHook.cpp:85
2 	xul.dll 	mozilla::widget::TaskbarPreview::Disable 	widget/src/windows/TaskbarPreview.cpp:237
3 	xul.dll 	mozilla::widget::TaskbarTabPreview::Disable 	widget/src/windows/TaskbarTabPreview.cpp:254
4 	xul.dll 	mozilla::widget::TaskbarPreview::SetVisible 	widget/src/windows/TaskbarPreview.cpp:163
5 	xul.dll 	mozilla::widget::TaskbarTabPreview::SetVisible 	widget/src/windows/TaskbarTabPreview.h:61
6 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
7 	xul.dll 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:2728
8 	xul.dll 	XPC_WN_GetterSetter 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1806
9 	mozjs.dll 	js_Invoke 	js/src/jsinterp.cpp:1364
10 	mozjs.dll 	js_InternalInvoke 	js/src/jsinterp.cpp:1429
11 	mozjs.dll 	js_SetPropertyHelper 	js/src/jsobj.cpp:5475
12 	mozjs.dll 	js_Interpret 	js/src/jsops.cpp:1872
13 	mozjs.dll 	js_Invoke 	js/src/jsinterp.cpp:1372
14 	mozjs.dll 	js_InternalInvoke 	js/src/jsinterp.cpp:1429
15 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:4957
16 	xul.dll 	nsJSContext::CallEventHandler 	dom/base/nsJSEnvironment.cpp:2161
17 	xul.dll 	nsJSEventListener::HandleEvent 	dom/src/events/nsJSEventListener.cpp:228
18 	xul.dll 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:1082
19 	xul.dll 	nsEventListenerManager::HandleEvent 	content/events/src/nsEventListenerManager.cpp:1198
20 	xul.dll 	nsEventTargetChainItem::HandleEvent 	content/events/src/nsEventDispatcher.cpp:201
21 	xul.dll 	nsEventTargetChainItem::HandleEventTargetChain 	content/events/src/nsEventDispatcher.cpp:326
Are you sure this still crashes? I can't find any crashes on crash-stats.

Until we're sure of how frequently this happens, I will have to say this doesn't block.
blocking2.0: ? → -
I would really like to see a VMWare recording of this crash or some STR. If I had to guess what the state of the TaskbarTabPreview was, mWnd is non-NULL but nsWindow::GetNSWindowPtr is null which is a very odd state to be in.
I was getting this crash a couple of times, while minimizing a testcase for bug 584251. I got it while closing Minefield.
we had an older bug with the same signature (bug 530962), but this sounds like a recent volume regression on trunk.  Around #11 or #12 topcrash on firefox 4.0b4 and b5, whereas the ranking on 3.6.9 is round #29.  Could be the same crash in both releases and a way to calibrate the two, but we should also check for any code that might have changed that might have made this worse or created different bugs.  we are running at about 1000 crashes per day across all releases and not the 10 per day mentioned in comment 2.  Steady growth since June, but also some sharp spikes around July 20th

date    crash_count

20100601 147
20100602 123
20100603 105
20100604 110
20100605 106

20100701 216
20100702 207
20100703 224
20100704 214
20100705 243

20100718 314
20100719 355
20100720 504
20100721 2027
20100722 1526
20100723 688
20100724 934
20100725 912

20100801 879
20100802 897
20100803 858
20100804 845
20100805 900

20100901 1052
20100902 1091
20100903 971
20100904 938
20100905 1011
looks like that spike from July 21 is 3.6.7 volume but in pct. terms the trunk was also high there.

checking --- mozilla::widget::WindowHook::Lookup.unsigned.int. 20100721-crashdata.csv
found in: 3.6.7 3.6.6 4.0b1 3.6.3 4.0b2pre 3.6b5 3.6 3.6b2 3.6.2 4.0b3pre 3.7a2 3.6b4 3.6b3 3.6.8pre
release total-crashes
              mozilla::widget::WindowHook::Lookup.unsigned.int. crashes
                         pct.
all     931161  2027    0.00217685
3.6.7   670536  1757    0.00262029
3.6.6   127716  143     0.00111967
4.0b1   20229   74      0.00365811
3.6.3   16172   26      0.00160772
4.0b2pre1471    11      0.00747791

also, 
any more thoughts on the connection to bug 584251 as suggested in comment 5?
blocking2.0: - → ?
in a sample of 100 crashes from yesterday looking at the top 6 frames of the stack it looks like there are 6 different stacks but might be variations of remove monitor and add monitor

WindowHook::Lookup
RemoveMonitor
TaskbarPreview::DetachFromNSWindow
http://crash-stats.mozilla.com/report/index/2bd64c8d-58c6-47ca-8273-e59712100912

and

WindowHook::Lookup
LookupOrCreate(unsigned int)
WindowHook::AddMonitor

http://crash-stats.mozilla.com/report/index/2eb892bf-ddcb-4c4b-b6c6-1f90f2100912
I'd like it renew my request from comment 3. It seems like this is a race condition that I am very unreliably able to hit on my own machine. If someone can catch this under VMWare R&R, I can (help) debug this remotely. This was invaluable towards solving a similar crash earlier this year in a matter of an hour vs the hours I spent staring at the source.
Depends on: 596222
One of the comments in the breakpad reports mentioned the MaxTo program, which makes Firefox crash reproducible with this stacktrace on shutdown. I filed bug 596222 for it.
Other instances when people are crashing with this stacktrace, that I've noticed.
- Directly on startup.
- While a (flash) plugin seems to be chewing up all cpu, causing Firefox to hang. Then the user tries to close Firefox.
When this crash occurs, during shutting down firefox process, window is destroyed at first, then, TaskbarWindowPreview is detroyed (depeded on GC).  So TaskbarWindowPreview uses invalid hook object.  So I think that all hooks may have to watch WM_DESTORY.

As long as I check crash reporter' log, this crash still occurs on 4.0b7pre

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A4.0b7pre&query_search=signature&query_type=startswith&query=mozilla%3A%3Awidget%3A%3AWindowHook%3A%3ALookup&date=10%2F04%2F2010%2023%3A39%3A16&range_value=1&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=mozilla%3A%3Awidget%3A%3AWindowHook%3A%3ALookup%28unsigned%20int%29
Assignee: nobody → tellrob
(In reply to comment #12)
> When this crash occurs, during shutting down firefox process, window is
> destroyed at first, then, TaskbarWindowPreview is detroyed (depeded on GC).  So
> TaskbarWindowPreview uses invalid hook object.  So I think that all hooks may
> have to watch WM_DESTORY.

Does this mean that you can reliably reproduce the crash? (I cannot). I'm curious how we're destroying the nsWindow because I'm pretty sure I verified 6+ months ago that all destruction paths did proper cleanup/notification.
(In reply to comment #13)

> Does this mean that you can reliably reproduce the crash? (I cannot). I'm
> curious how we're destroying the nsWindow because I'm pretty sure I verified 6+
> months ago that all destruction paths did proper cleanup/notification.

I cannot reproduce this, but I think that crash reason is clear if you analyze stack and imagine situation why crashing.
mozilla::widget::WindowHook is already destroyed when crash occurs.  It mean this of WindowHook is NULL.

This bug depends on GC timing. (when TaskbarTabPreview is destroyed by GC.) And root cause is that TaskbarPreview doesn't know whether WindowHook is alive.
GC bugs usually are concetrated on winXP or across OSes.  Its strange that this one might be exclusively win7

os breakdown for crashes on 2010 10 20
1064 Windows NT 6.1. mozilla::widget::WindowHook::Lookup(unsigned int)

1061    0.99718 Windows NT6.1.7600
1       0.00093985      Windows NT6.1.7601 Service Pack 2, v.172
1       0.00093985      Windows NT6.1.7601 Service Pack 1, v.153
1       0.00093985      Windows NT6.1.7100

looking at possible test urls there are these indicate possible private browsing and downloading activity going on.   they might help to tickle GC

  61 about:blank
  51 \N
  12 about:privatebrowsing
   9 http://get.adobe.com/flashplayer/download/?installer=Flash_Player_10.1_for_Windows_-_Other_Browsers&a=McAfee_Security_Scan_Plus&os=Wind
ows%207&browser=Firefox&type=xpi
   7 http://get.adobe.com/flashplayer/download/?installer=Flash_Player_10.1_for_Windows_-_Other_Browsers&d=McAfee_Security_Scan_Plus&os=Wind
ows%207&browser=Firefox&type=xpi
   3 http://ff.conduit-download.com/27/243/ct2438727/downloads/firefox/releases/2.7.1.3/10-06-30-00.13.44.677/zynga.xpi
  2 http://get2.adobe.com/flashplayer/download/?installer=Flash_Player_10.1_for_Windows_-_Other_Browsers&a=McAfee_Security_Scan_Plus&os=Win
dows%207&browser=Firefox&type=xpi
   2 http://get.adobe.com/reader/download/?installer=Reader_9.4_English_for_Windows&a=McAfee_Security_Scan_Plus&a=ARH&a=Air_Installer&os=Win
dows%207&browser=Firefox&type=xpi
   2 http://get.adobe.com/fr/flashplayer/download/?installer=Flash_Player_10.1_for_Windows_-_Other_Browsers&d=McAfee_Security_Scan_Plus&os=W
indows%207&browser=Firefox&type=xpi
   2 http://get.adobe.com/es/flashplayer/download/?installer=Flash_Player_10.1_for_Windows_-_Other_Browsers&a=McAfee_Security_Scan_Plus&os=W
indows%207&browser=Firefox&type=xpi
   2 http://get.adobe.com/de/flashplayer/download/?installer=Flash_Player_10.1_for_Windows_-_Other_Browsers&a=McAfee_Security_Scan_Plus&os=W
indows%207&browser=Firefox&type=xpi

some facebook activity

   8 http://www.facebook.com/#!/
   6 http://www.google.de/
   6 http://www.facebook.com/?ref=home
   6 http://www.facebook.com/
   2 http://apps.facebook.com/frontierville/?crt&aff=bookmarks&src=bookmark&newUser&sendkey&ref=bookmarks
   2 http://apps.facebook.com/cartown/?ref=bookmarks&count=0

justin tv and google talk gaget wyciwyg cache

   1 wyciwyg://68/http://www.justin.tv/family_guy_5ucks_b4lls
   1 wyciwyg://3/http://talkgadget.google.com/talkgadget/notifierclient?client=sm&prop=Orkut&nav=true&fid=gtn-roster-iframe-id&ts=0&debug=un
defined&os=Win32&stime=1287597752609&fb=false&re=false&no=undefined&hc=undefined&ref=undefined&xpc=%7B%22cn%22%3A%22idku
   1 wyciwyg://3/http://ru.justin.tv/radiotrance_189
   1 wyciwyg://15/http://sn140w.snt140.mail.live.com/mail/InboxLight.aspx?n=444610932


and some session restore/(re-)startup

   5 jar:file:///C:/Program%20Files/Mozilla%20Firefox%204.0%20Beta%205/omni.jar!/chrome/browser/content/browser/aboutSessionRestore.xhtml
   5 http://www.yahoo.com/
   5 http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official
   4 http://www.google.com/ig?refresh=1
   3 http://www.orkut.com/Logout?msg=0&hl=pt-BR
   3 http://www.mozilla.com/en-US/firefox/3.6.11/whatsnew/
   3 http://www.google.com/ig
   3 http://www.facebook.com/home.php?#!/
   3 http://de.start3.mozilla.com/firefox?client=firefox-a&rls=org.mozilla:de:official
   2 https://suomi.sampopankki.fi/link/FuncStat?opendocument&FuncStat=eSecureKeyFIInit
   2 https://mail.google.com/mail/?shva=1#inbox
   2 http://www.yandex.ru/
   2 http://www.google.de/firefox?client=firefox-a&rls=org.mozilla:de:official
  10 http://en-us.start3.mozilla.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official
also a bunch of viewing of pages on addons.mozilla.org and possible download and installation of addons going on.  some kind of downloading (maybe while in private browsing) while viewing videos or playing games on facebook to generally keep the browser busy, then shut down?

https://bugzilla.mozilla.org/show_bug.cgi?id=584251#c7 has Martiin's test case where he was testing that other bug and stubbled on to this signature.  The key there was also getting the browser at high levels of activity then trying to shut down.
(In reply to comment #14)
> (In reply to comment #13)
> 
> > Does this mean that you can reliably reproduce the crash? (I cannot). I'm
> > curious how we're destroying the nsWindow because I'm pretty sure I verified 6+
> > months ago that all destruction paths did proper cleanup/notification.
> 
> I cannot reproduce this, but I think that crash reason is clear if you analyze
> stack and imagine situation why crashing.
> mozilla::widget::WindowHook is already destroyed when crash occurs.  It mean
> this of WindowHook is NULL.
> 
> This bug depends on GC timing. (when TaskbarTabPreview is destroyed by GC.) And
> root cause is that TaskbarPreview doesn't know whether WindowHook is alive.

It should though because each TaskbarPreview listens for WM_DESTROY and explicitly marks that the window is gone by setting mWnd to NULL. My guess is that we're not getting these sometimes. I've attached a possible fix which makes sure that we dispatch those in the case where our toplevel window is for some reason subclassed and dropping WM_DESTROY messages. I don't understand the teardown code very well so I am asking Jim to review this to see if that sounds plausible.
Attachment #485157 - Flags: review?(jmathies)
I don't understand why we think this will address the problem. Do we really think sub classes that filter the destroy message are this common?
(In reply to comment #18)
> I don't understand why we think this will address the problem. Do we really
> think sub classes that filter the destroy message are this common?

I'm out of other ideas (please feel free to suggest issues) so I am resorting to trying to prove that all code paths are safe. Unless someone catches this under VMWare Record & Reply or comes up with reliable steps to reproduce, I don't think this will get fixed.
Comment on attachment 485157 [details] [diff] [review]
Ensure we dispatch WM_DESTROY if we're subclassed

Unless this drops the occurrences to zero, lets keep this open. I can find some time to play with this in a recording session.
Attachment #485157 - Flags: review?(jmathies) → review+
http://hg.mozilla.org/mozilla-central/rev/b14f7ebae437
Status: NEW → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
Let's keep this open until the crash stats show it's fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
here is an update on volume across releases.  lets recheck these numbers after beta8


checking --- mozilla::widget::WindowHook::Lookup.unsigned.int. 20101213-crashdata.csv
found in: 3.6.13 4.0b7 3.6.12 3.6.3 3.6 3.6.8 4.0b6 3.6.2 3.6.10 3.6b5 3.6b4 4.0b8pre 4.0b4 3.6b2 4.0b1 3.6b3 3.6.9 3.6.7 3.6.6 4.0b5 4.0b3
release total-crashes
              mozilla::widget::WindowHook::Lookup.unsigned.int. crashes
                         pct.
all  	338233	1124	0.00332315
3.6.13	164371	367	0.00223275
4.0b7	42486	282	0.00663748
3.6.12	46897	175	0.00373158
3.6.3	7848	146	0.0186035
3.6	5247	63	0.0120069
3.6.8	7317	21	0.00287003
4.0b6	2848	13	0.00456461
3.6.2	1507	16	0.0106171
3.6.10	7657	12	0.00156719
3.6b5	632	6	0.00949367
3.6b4	425	5	0.0117647
4.0b8pre5689	4	0.000703111
4.0b4	880	4	0.00454545
3.6b2	339	3	0.00884956
4.0b1	814	2	0.002457
rank is #33 on 3.6.13 v. #14 on 4.0b7
Whiteboard: [softblocker]
This is definitely not fixed.

Mounir, do you have Windows?

Without a testcase, or steps to reproduce, we might need to null-check our way to victory.

Some of the stacks are unusual:
https://crash-stats.mozilla.com/report/index/b52046cd-8863-4409-b420-ddd122110131
https://crash-stats.mozilla.com/report/index/c513b766-15f6-4130-ba70-c2d9b2110201

Here we're actually crashing on creating the preview, because we get a null hook. I wonder if we could possible be getting an mWnd that has *already* had WM_DESTROY called on it? Maybe we should try checking in CreateTaskbarTabPreview whether the nsWindow for the toplevelHWND can be found, and refuse to create the preview if not. That's wallpaper-ish but it's safe and will either make these crashes go away or narrow down the problem.
Assignee: tellrob → nobody
(In reply to comment #27)
> This is definitely not fixed.
> 
> Mounir, do you have Windows?

Unfortunately, I don't. But I'm planning to install a VM on my desktop so I will have a look at that bug at this moment if it's not fixed in the mean time.
Target Milestone: mozilla2.0b8 → ---
Worth a shot. Many of the comments suggest plugin interactions (flash games, divx), so something might be generating messages at unexpected times.
There are also some startup crashes, which are even weirder.

I thought bug 608589 might be related to this but it's been marked as fixed for 4b10 and this crash didn't disappear
Attachment #509572 - Flags: review?(roc)
Assignee: nobody → felipc
Attachment #509572 - Flags: review?(tellrob)
I don't think we should wait for rob's review here. Just land it!
Landed
http://hg.mozilla.org/mozilla-central/rev/019e47cc11e2

I'll keep the r? if rob wants to take a look
Comment on attachment 509572 [details] [diff] [review]
Check for nsWindow existence before creating the preview

I'm pretty sure this will cause UI bustage in the error case since other parts of the frontend code assume a 1:1 correspondence of tabs and previews. I also don't think this code had proper review for the browser/ part so it should not have landed.
Attachment #509572 - Flags: review?(tellrob) → review-
OK, we can back it out.

However, I think that some kind of UI bustage is preferable to crashing.
At least I think we should leave it in for a few days to a) see if it fixed the crashes and b) see if anyone notices UI bustage that could be related to this.
I still see this crash signature in builds from 4 Feb on...
I'm renominating this bug as a hardblocker because we should remember to backout the latest test patch before the final version, it was uneffective, plus comment 32.
blocking2.0: final+ → ?
Whiteboard: [softblocker]
OK. Felipe, can you back this out?
blocking2.0: ? → final+
Whiteboard: [hardblocker][needs backout]
Backed out at http://hg.mozilla.org/mozilla-central/rev/d05be9356e44
Whiteboard: [hardblocker][needs backout] → [softblocker]
Felipe, did you meant to change this bug from hardblocker to softblocker?
Yeah, it was a softblocker before, we just marked hardblocker to remember to back out the last fix attempt
** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage
blocking2.0: final+ → .x+
Crash Signature: [@ mozilla::widget::WindowHook::Lookup(unsigned int)]
https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Awidget%3A%3AWindowHook%3A%3ALookup%28unsigned%20int%29 says this signature happens across the board - what's the status of this? I guess the "3.6" can be removed from the summary?
This crash still appears on recent. Looks like a Windows 7 specific issue. On 9.0b3 there are 150 crashes total so far. On 8.0 we had over 3000 in the past 4 weeks.
Summary: Taskbar tab preview crashes [@ mozilla::widget::WindowHook::Lookup(unsigned int)] in Firefox 3.6 at SetVisible → Taskbar tab preview crashes [@ mozilla::widget::WindowHook::Lookup(unsigned int)] at SetVisible
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #11)
> - Directly on startup.

Should startup crashes be considered in a different bug?

I have a user who, after updating to version 10, is now crashing on startup. Reinstall doesn't help. Safe mode starts, but the safe mode window is empty.  His crashes are
bp-3c619a32-20f5-41fe-98fb-520482120213
bp-0e9ce577-2657-49a8-ab06-568d22120213

other users startup crashes:
bp-bc5c9b4e-e1a2-4805-9728-b35ee2120120
bp-6b2c1bb6-271f-4331-9aca-32f252120207
bp-57c8034e-146d-42bc-a6b0-964312120205
bp-23f158d0-2158-4b13-95f4-a77de2120212
here is what we had seen starting safemode

(In reply to Wayne Mery (:wsmwk) from comment #45)
> Should startup crashes be considered in a different bug?
> 
> I have a user who, after updating to version 10, is now crashing on startup.
> Reinstall doesn't help. Safe mode starts, but the safe mode window is empty.
> His crashes are
> bp-3c619a32-20f5-41fe-98fb-520482120213
> bp-0e9ce577-2657-49a8-ab06-568d22120213

after rebooting his win7 system, firefox now starts
Confirm for Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121010030605 

Crash: https://crash-stats.mozilla.com/report/index/bp-6bb5f3f1-49fe-457e-81d8-cc8082121011
Not at all frequent, but it is still around in Fx39. 

From a sumo thread.

bp-9a711c79-b774-414a-b14a-e5e5d2150723
Windows NT OS Version 	6.1.7601 Service Pack 1 Firefox 39.0 Build ID 	20150630154324
> User Comments 	I was shutting down my PC and clicked on Firefox menu (3 bars), to the right at the top of the screen, so that I may properly close down Firefox. When the Firefox menu opened I clicked on the 'close' button and then up popped the Mozilla Crash Reporter. As I had closed everything down I would not have known that Firefox has crashed except for this Crash Reporting making itself available, did i I had closed all pages and had nothing open, no applications, no tab. Nothing was open.

I will ask the user for more information, or ask the person to post here if it helps at all.
The user has remarked along the lines that Firefox is now used regularly but has not crashed often.
Assignee: felipc → nobody
Crash Signature: [@ mozilla::widget::WindowHook::Lookup(unsigned int)] → [@ mozilla::widget::WindowHook::Lookup(unsigned int)] [@ mozilla::widget::WindowHook::Lookup]
Based on Socorro reports from last 28 days, this crash is encounter frequently. We shouldn't close this issue until there are no more crashes.
Depends on: 1277156
Depends on: 1277167
This is still occurring in the wild on release branches (including beta).  However, no reports against dev branches.
Whiteboard: [softblocker] → [softblocker][tpi:+]
Crash volume for signature 'mozilla::widget::WindowHook::Lookup':
 - nightly (version 51): 12 crashes from 2016-08-01.
 - aurora  (version 50): 39 crashes from 2016-08-01.
 - beta    (version 49): 244 crashes from 2016-08-02.
 - release (version 48): 475 crashes from 2016-07-25.
 - esr     (version 45): 583 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly       3       3       3
 - aurora       14      16       3
 - beta         89      84      26
 - release     145     132      82
 - esr          71      55      57

Affected platform: Windows

Crash rank on the last 7 days:
           Browser     Content   Plugin
 - nightly #187
 - aurora  #95
 - beta    #188
 - release #125
 - esr     #114
Status: REOPENED → RESOLVED
Closed: 9 years ago3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1277167
You need to log in before you can comment on or make changes to this bug.