The implementation of worker.tab contains a rather bizarre incantation: > topContentWindow= win.QueryInterface(Ci.nsIInterfaceRequestor) > .getInterface(Ci.nsIWebNavigation) > .QueryInterface(Ci.nsIDocShellTreeItem) > .treeOwner > .QueryInterface(Ci.nsIInterfaceRequestor) > .getInterface(Ci.nsIDOMWindow); This QIs its way up to XUL and back down again, always landing us in the active tab. This means that worker.tab is equivalent to require("tabs").activeTab, which is much less useful than the advertised behavior.
Created attachment 523210 [details] [diff] [review] patch+tests v1 Attached a patch and tests to fix the issue.
Assignee: nobody → bobbyholley+bmo
Status: NEW → ASSIGNED
Nice catch! Unfortunately I think that win.top is going to throw domain access denied exception on iframe with different domain that upper document. I'm going to take a look at this. Thanks for the patch and this unit test is very usefull.
Comment on attachment 523210 [details] [diff] [review] patch+tests v1 Nice catch! r=myk
Attachment #523210 - Flags: review?(myk) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(In reply to comment #2) > Nice catch! > > Unfortunately I think that win.top is going to throw domain access denied > exception on iframe with different domain that upper document. I didn't test it, but I'd assumed this wouldn't happen because the script is running with chrome context, not the context of the upper document. Given that this was pushed, I assume this concern was resolved? I just wanted to make sure.
I verified with differents domains and win.top still works. So we can consider this as fixed.
You need to log in before you can comment on or make changes to this bug.