Closed
Bug 908277
Opened 11 years ago
Closed 11 years ago
Make sure the background thumbnail service can't open permission UI
Categories
(Toolkit :: General, defect)
Toolkit
General
Tracking
()
RESOLVED
FIXED
mozilla28
People
(Reporter: evilpie, Assigned: adw)
References
(Blocks 1 open bug)
Details
(Whiteboard: [qa-])
Attachments
(1 file)
894 bytes,
patch
|
Dolske
:
review+
|
Details | Diff | Splinter Review |
As I work on fixing all the permission UI stuff for Notifications, Geolocation etc. I have the feeling that those could actually pop up when we remote capture something? Unless of course we disable JavaScript.
Assignee | ||
Updated•11 years ago
|
OS: Linux → All
Product: Firefox → Toolkit
Hardware: x86_64 → All
Summary: Make sure that the page thumbnails can't open permission ui → Make sure the background thumbnail service can't open permission UI
Comment 1•11 years ago
|
||
I don't think this is a problem, as browser.js isn't used for the <browser> element we use for remote captures (and IIUC, this is what does all the permission UI stuff)
Assignee | ||
Comment 2•11 years ago
|
||
Fortunately no doorhangers appear anywhere, but a couple of exceptions are thrown because the background thumbnail browser is in the hidden window rather than browser.xul. This one for geolocation:
[Exception... "'[JavaScript Error: "link is null" {file: "file:///Users/adw/fx/obj-debug/dist/NightlyDebug.app/Contents/MacOS/browser/components/nsBrowserGlue.js" line: 1823}]' when calling method: [nsIContentPermissionPrompt::prompt]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: yes]
And this one for desktop-notification and pointerLock:
[Exception... "'[JavaScript Error: "chromeWin.PopupNotifications is undefined" {file: "file:///Users/adw/fx/obj-debug/dist/NightlyDebug.app/Contents/MacOS/browser/components/nsBrowserGlue.js" line: 1766}]' when calling method: [nsIContentPermissionPrompt::prompt]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: yes]
This patch prevents the errors by returning early from ContentPermissionPrompt.prototype.prompt when the browser's host chrome window doesn't have PopupNotifications.
Attachment #818166 -
Flags: review?(dolske)
Comment 3•11 years ago
|
||
The null check of PopupNotifications is better than other methods of determining the window suitability because we have things like chatWindow.xul that still want to support notifications but aren't browser.xul. That probably means the comment should be tweaked, though.
I'm not sure that "get rid of the exception" is a desirable goal here, though. Throwing a better exception ("window doesn't support notifications" or somesuch) earlier on makes sense rather than letting things fail in various ways later, but it still seems like throwing an exception is the better thing to do.
Assignee | ||
Comment 4•11 years ago
|
||
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #3)
> That probably means the comment should be tweaked, though.
That makes sense.
> I'm not sure that "get rid of the exception" is a desirable goal here,
> though. Throwing a better exception ("window doesn't support notifications"
> or somesuch) earlier on makes sense rather than letting things fail in
> various ways later, but it still seems like throwing an exception is the
> better thing to do.
Do you have an idea of where such an exception should be thrown? It looks like the prompt() method here is called directly from code in dom/, so this is the first place the call stack enters browser/, which seems to me the right place to determine whether the window supports notifications.
But I'm just trying to prevent any permission prompt exception from going uncaught, so I don't think it would be right to throw an exception with no way to catch and suppress it when you know beforehand it's not going to work.
Comment 5•11 years ago
|
||
Throwing an exception where you're currently just returning in that patch would be fine, I think. nsIContentPermissionPrompt callers should be responsible for dealing with failures accordingly.
But that won't solve your exception reporting problem, because we don't have a fix for bug 738119 yet :/ Maybe we can push on that bug.
Updated•11 years ago
|
Attachment #818166 -
Flags: review?(dolske) → review+
Assignee | ||
Comment 6•11 years ago
|
||
Assignee: nobody → adw
Status: NEW → ASSIGNED
Comment 7•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Updated•11 years ago
|
Whiteboard: [qa-]
You need to log in
before you can comment on or make changes to this bug.
Description
•