Closed Bug 597031 Opened 9 years ago Closed 9 years ago
Exception thrown when trying to use create
Taskbar Tab Preview
See testcase, which uses enhanded privileges. This used to work in older builds, but in newer trunk builds, I get this js error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIWinTaskbar.createTaskbarTabPreview]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: file:///C:/Users/mw22/Desktop/test1.html :: taskbarpreview :: line 19" data: no] This regressed between 2010-08-028 and 2010-08-29: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-08-27+04%3A00%3A00&enddate=2010-08-28+08%3A00%3A00 I guess a regression from bug 130078.
We try to get the widget from the docshell here http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/WinTaskbar.cpp#357 but the docshell does not have a widget anymore. The tab previews code seems to call the same function same with a tab's docshell, but the tab previews are still working fine, I'm not sure why.
The tab previews don't use the tab's docshell. They use the one for the browser's XUL window.
Ok, so any reason we want to support what this testcase is trying to do then?
Because it used to work? But anyway, if you want to invalidate this bug, feel free. Any pointer on how to get the browser's XUL window docshell, though?
You can get the parent docshell using this var docShellTreeItem = docShell.QueryInterface(Components.interfaces.nsIDocShellTreeItem); var parent = docShellTreeItem.parent; You can walk the parent chain up until you have the docshell you want. You can check parent.itemType to see what type of docshell you have and verify that it is chrome, chrome is type 0, content is type 1. You'd also probably need to QI parent above back to a nsIDocShell from nsIDocShellTreeItem. Does that work for you?
Indeed, only toplevel nsIDocShells have widgets, so the documentation should say that only toplevel docshells should be used.
(In reply to comment #5) > You can get the parent docshell using this > > var docShellTreeItem = > docShell.QueryInterface(Components.interfaces.nsIDocShellTreeItem); > var parent = docShellTreeItem.parent; > You can walk the parent chain up until you have the docshell you want. You can > check parent.itemType to see what type of docshell you have and verify that it > is chrome, chrome is type 0, content is type 1. You'd also probably need to QI > parent above back to a nsIDocShell from nsIDocShellTreeItem. Does that work for > you? I tried something like this: var docShellTreeItem = docShell.QueryInterface(Components.interfaces.nsIDocShellTreeItem); var parent = docShellTreeItem.parent; var ds = parent.QueryInterface(Components.interfaces.nsIDocShell); I still get the same js error and I can't go any higher in the parent chain. Am I doing something wrong?
Did you check the itemType of the docshell you got to verify that it was chrome?
And you'd need UniversalXPConnect, but I think your original testcase had that too.
(In reply to comment #9) > Did you check the itemType of the docshell you got to verify that it was > chrome? itemType returns 0 (=Chrome as you mentioned in comment 5) and yes, I use UniversalXPConnect, just like the testcase I attached.
I don't know. I just tried the code from comment 8 and it worked for me on Windows 7.
Sorry, never mind. Indeed, it seems to work. I guess I got confused by previous error messages in the error console. Thanks for the help. This bug can be closed as soon as the documentation is updated to reflect current reality.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
The documentation in here is still incorrect: http://mxr.mozilla.org/mozilla-central/source/widget/public/nsIWinTaskbar.idl
I put this patch in my queue to update that, I will land it the next time I land.
Landed the comment fix http://hg.mozilla.org/mozilla-central/rev/9cc9952ecc89
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.