Open
Bug 721336
Opened 12 years ago
Updated 2 years ago
Ban sync XMLHttpRequest with chrome privileges
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
NEW
People
(Reporter: hsivonen, Unassigned)
References
Details
(Whiteboard: [snappy:p3])
To make it harder for extensions to be un-Snappy, we should ban synchronous XHR from chrome. However, we might need to make an exception for xpcshell tests (see bug 717566). Also Orion had an instance of sync XHR use. Need to check if that bit runs as chrome or not.
Comment 1•12 years ago
|
||
What's the time frame on this? I assume it won't land in FF 10 or 11.
Comment 2•12 years ago
|
||
No. This won't be in FF12 either. FF13 at earliest, I think.
Reporter | ||
Comment 3•12 years ago
|
||
It might make sense to add a console warning first and then wait for at least one cycle before making sync XHR with chrome privileges actually throw.
Updated•12 years ago
|
Whiteboard: [Snappy] → [Snappy:p4]
Comment 4•12 years ago
|
||
I keep accidentally using a non-existent snappy:p4 priority
Whiteboard: [Snappy:p4] → [snappy:p3]
Will it still be okay to use synchronous XHR with file:// or chrome:// arguments? Sometimes it is the easiest loading method.
Reporter | ||
Comment 6•12 years ago
|
||
(In reply to R Pruitt from comment #5) > Will it still be okay to use synchronous XHR with file:// or chrome:// > arguments? Sometimes it is the easiest loading method. I was thinking of banning *all* synchronous chrome-privileged XHR. Local disk access isn't instantaneous. (And file:// URLs can actually point to network shares.)
Comment 7•7 years ago
|
||
Is this still something we plan on doing? If so, now would be a good time to do it given everyone has to rewrite extensions.
Flags: needinfo?(hsivonen)
Updated•7 years ago
|
Summary: Ban sync XHR with chrome privileges → Ban sync XMLHttpRequest with chrome privileges
Reporter | ||
Comment 8•7 years ago
|
||
(In reply to Anne (:annevk) from comment #7) > Is this still something we plan on doing? I'd hope so. > If so, now would be a good time to > do it given everyone has to rewrite extensions. Indeed. kmaglione, are you aware for reasons against doing this? Do WebExtensions run under the chrome principal?
Flags: needinfo?(hsivonen) → needinfo?(kmaglione+bmo)
Comment 9•7 years ago
|
||
(In reply to Henri Sivonen (:hsivonen) from comment #8) > kmaglione, are you aware for reasons against doing this? No, and I'm strongly in favor of it. > Do WebExtensions run under the chrome principal? No, they run under codebase principals with slightly expanded privileges. Ideally, I'd love to ban sync XHRs for WebExtension principals too, but that would break too many extensions at this point.
Flags: needinfo?(kmaglione+bmo)
Updated•6 years ago
|
Priority: -- → P3
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•