Closed
Bug 930069
Opened 11 years ago
Closed 10 years ago
Deprecate unsafeWindow and issue a deprecation warning if it is used.
Categories
(Add-on SDK Graveyard :: General, defect)
Add-on SDK Graveyard
General
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: canuckistani, Unassigned)
References
Details
We're cleaning up a bunch of implementation warts and want to eventually replace unsafeWindow with a better api that Gabor is working on. In order to transition smoothly, we should start to issue a deprecation warning when unsafeWindow is used in content scripts, ASAP.
Comment 1•11 years ago
|
||
We can't deprecate until we have an alternative
Reporter | ||
Comment 2•11 years ago
|
||
(In reply to Dave Townsend (:Mossop) from comment #1)
> We can't deprecate until we have an alternative
Agreed, but Gabor would have me believe this is imminent. So I guess this should be possible once th enew apis are in place?
Comment 3•11 years ago
|
||
What I know of the APIs is that they expose chrome stuff to content. But don't many add-ons use unsafeWindow to get at content stuff from chrome?
Comment 4•11 years ago
|
||
Actually both direction should be addressed. But Dave is right, we still need to provide a nice high level API on top of the low level version I landed. And the API I landed is only available on nightly right now...
On the other hand according to our documentation: "Also, unsafeWindow isn't a supported API, so it could be removed or changed in a future version of the SDK."
Anyway I would save this bullet after we have the docs in place for the new API or something. So once we get the attention of add-on developers with this warning we can point them to the new shiny API they can use instead.
Reporter | ||
Comment 5•11 years ago
|
||
If we're going to deprecate something, it's P1. Deprecating unsafeWindow involves having a viable alternative.
Priority: -- → P1
Comment 6•11 years ago
|
||
I talked to Bobby about this. So unsafeWindow does not have to be deprecated but there were restrictions there. When someone does unsafeWindow.foo = {...} that object will be opaque for content. To warn add-on developers about this upcoming change I think we have to do the warning thing from platform side.
Blocks: SH-addons
Comment 7•10 years ago
|
||
things have changed..
OS: Mac OS X → All
Priority: P1 → --
Hardware: x86 → All
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•