If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Exception thrown when trying to use createTaskbarTabPreview

RESOLVED WORKSFORME

Status

()

Core
Layout: View Rendering
RESOLVED WORKSFORME
7 years ago
7 years ago

People

(Reporter: Martijn Wargers (dead), Unassigned)

Tracking

({dev-doc-complete})

Trunk
x86
Windows 7
dev-doc-complete
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

7 years ago
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?
(Reporter)

Comment 4

7 years ago
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?
The fix is much easier to do in JavaScript than in C++ code so I'm inclined to not fix this. The documentation should be updated (if it is not already) to indicate that we only want nsIDocShells that have native widgets (and really, only toplevel ones at that - 130078 simplified things).
Indeed, only toplevel nsIDocShells have widgets, so the documentation should say that only toplevel docshells should be used.
(Reporter)

Comment 8

7 years ago
(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.
(Reporter)

Comment 11

7 years ago
(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.
(Reporter)

Comment 13

7 years ago
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

7 years ago
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME

Updated

7 years ago
Keywords: regression, testcase → dev-doc-needed
Updated documentation:

https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIWinTaskbar#createTaskbarTabPreview%28%29
Keywords: dev-doc-needed → dev-doc-complete
(Reporter)

Comment 15

7 years ago
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
You need to log in before you can comment on or make changes to this bug.