Closed
Bug 1127577
Opened 10 years ago
Closed 10 years ago
NS_ERROR_FAILURE in nsITaskbarTabPreview.invalidate
Categories
(Firefox :: Shell Integration, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox39 | --- | fixed |
People
(Reporter: vladan, Assigned: markh)
References
Details
(Keywords: regression)
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
markh
:
review+
|
Details | Diff | Splinter Review |
I see this error repeated many times in the Nightly error console:
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)[nsITaskbarTabPreview.invalidate]1 WindowsPreviewPerTab.jsm:401:0
I suspect it's caused by bug 526620
Reporter | ||
Updated•10 years ago
|
Flags: needinfo?(tellrob)
Reporter | ||
Updated•10 years ago
|
Flags: needinfo?(jmathies)
Comment 1•10 years ago
|
||
Looks like a fairly passive failure we can catch and ignore:
http://mxr.mozilla.org/mozilla-central/source/widget/windows/TaskbarPreview.cpp#185
Assignee | ||
Comment 2•10 years ago
|
||
I see this when the taskbar is set to autohide.
Something like this? I initially thought that if !mVisible, we should still invalidate the preview, but it appears that mVisible isn't tracking whether the taskbar itself is *currently* visible, so it seems OK.
Attachment #8567797 -
Flags: review?(jmathies)
Updated•10 years ago
|
Attachment #8567797 -
Flags: review?(jmathies) → review+
Comment 3•10 years ago
|
||
There are two calls in WindowsPreviewPerTab.jsm to this, one checks preview.visible first before making the call, the other doesn't. I don't think either should need to check visible first, we should remove that check as well.
Assignee | ||
Comment 4•10 years ago
|
||
Patch with requested change to WindowsPreviewPerTab.jsm, carrying r+ forward.
Try at https://treeherder.mozilla.org/#/jobs?repo=try&revision=a1259f724f0b and I'll land when it looks green.
Assignee: nobody → mhammond
Attachment #8567797 -
Attachment is obsolete: true
Attachment #8568964 -
Flags: review+
Assignee | ||
Comment 5•10 years ago
|
||
Status: NEW → ASSIGNED
Comment 6•10 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-firefox39:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 39
Comment 7•10 years ago
|
||
Hi Mark, can you provide a point value.
Iteration: --- → 39.1 - 9 Mar
Flags: qe-verify?
Flags: needinfo?(mhammond)
Flags: firefox-backlog?
Flags: firefox-backlog+
Assignee | ||
Updated•10 years ago
|
Points: --- → 1
Flags: needinfo?(mhammond)
Comment 8•10 years ago
|
||
Seems like a low impact issue, so not setting it for verification.
Flags: qe-verify? → qe-verify-
Comment 9•10 years ago
|
||
Mistakenly filed against Firefox 38 and should be instead 38 Branch. Sorry for the spam. dkl
Version: Firefox 38 → 38 Branch
Comment 10•9 years ago
|
||
I'm on Firefox 38.0.5b1 x64
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIInterfaceRequestor.getInterface] network-monitor.js:82:0
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsITaskbarTabPreview.invalidate] WindowsPreviewPerTab.jsm:406:0
I'm getting alot freezes and some time freeze forever and I need kill firefox process.
screen of my console
http://puu.sh/hK0IL/15d690b775.png
Assignee | ||
Comment 11•9 years ago
|
||
(In reply to Gabriel from comment #10)
> I'm getting alot freezes and some time freeze forever and I need kill
> firefox process.
>
> screen of my console http://puu.sh/hK0IL/15d690b775.png
I notice "lastpass" in the console, so assuming you are using Nightly, lastpass is almost certainly the problem - for me it makes Nightly unusable. Try disabling it and see if your problems stop. Bug 1008768 is tracking this (even though the title of that bug isn't quite up-to-date)
Comment 12•9 years ago
|
||
Hello, I just found this bug number when I found the commit that will hopefully fix this issue.
Is this targeted for 39? It would be nice to have it fixed also for 38 or 38.0.5.
Could someone please mark https://bugzilla.mozilla.org/show_bug.cgi?id=1151863 and https://bugzilla.mozilla.org/show_bug.cgi?id=1162155 as duplicates of this?
Reporter | ||
Comment 15•9 years ago
|
||
(In reply to Ricardo from comment #12)
> Is this targeted for 39? It would be nice to have it fixed also for 38 or
> 38.0.5.
That's right, this fix will be in Firefox 39. Firefox 38.0.5 was already released today as far as I know
You need to log in
before you can comment on or make changes to this bug.
Description
•