Created attachment 475878 [details] testcase (uses enhanced privileges) 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.
Created attachment 477490 [details] testcase2 (works) 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.
Updated documentation: https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIWinTaskbar#createTaskbarTabPreview%28%29
The documentation in here is still incorrect: http://mxr.mozilla.org/mozilla-central/source/widget/public/nsIWinTaskbar.idl
Created attachment 488600 [details] [diff] [review] update idl comment 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