Closed
Bug 799247
Opened 12 years ago
Closed 12 years ago
Adjust message in nsITransferable compatibility flag
Categories
(addons.mozilla.org Graveyard :: Compatibility Tools, defect)
addons.mozilla.org Graveyard
Compatibility Tools
Tracking
(Not tracked)
RESOLVED
FIXED
2012-10-11
People
(Reporter: jorgev, Assigned: basta)
Details
The message I proposed in bug 795423 has been pointed out to be incorrect in many cases, so we need to make some adjustments. The bump has already been made, so most developers will have seen the old message already, but we should correct it for future validations. New Message: The nsITransferable interface has changed to better support Private Browsing Mode. After instantiating the object, you should call the init function on it before any other functions are called. See <LINK> for more information. New Link: https://developer.mozilla.org/en-US/docs/Using_the_Clipboard
Comment 1•12 years ago
|
||
Jorge, just want to point out here as well in bug 722872 that it's unclear in the recent edits to https://developer.mozilla.org/en-US/docs/Using_the_Clipboard where the "sourceWindow" var comes from. Also, while I'm at it, some of the code samples on that page seems to have gotten badly munged (probably on transition from one CMS to another), resulting in HTML (like strong tags) showing up erroneously in the code samples, e.g. <strong>// make a copy of the Unicode</strong>
Comment 2•12 years ago
|
||
Jorge, is there some way to send out the compatibility warning again? The existing message totally negates the purpose of the change and could lead to private data being kept alive after leaving private browsing.
Reporter | ||
Comment 3•12 years ago
|
||
That would be confusing for developers, and they would probably disregard it as a duplicate.
Comment 4•12 years ago
|
||
Isn't there some messaging we could prefix it with to make it clearer? This is a really unfortunate situation, and I don't see why we need to just throw our hands up in despair.
Reporter | ||
Comment 5•12 years ago
|
||
You're right. We'll look into that once this bug is fixed in production.
Comment 6•12 years ago
|
||
We should probably also add a warning when nsITransferable.init() is called with null as the first argument.
Comment 7•12 years ago
|
||
Unfortunately null is valid in a number of common situations, so that's not workable.
Comment 8•12 years ago
|
||
The validator warns for a lot of things that are valid in a number of common situations. nsITransferable.init(null) is the kind of thing that developers and editors should think twice about, so it's the kind of thing we should warn for.
Reporter | ||
Comment 9•12 years ago
|
||
Kris, please file a separate bug for that, since it isn't a compatibility check.
Assignee | ||
Comment 10•12 years ago
|
||
Messaging updated: https://github.com/mozilla/amo-validator/commit/db11baaba76765de59e9072b8ad3bcb3560ed36b
Comment 11•12 years ago
|
||
Filed bug 800495.
Assignee | ||
Comment 12•12 years ago
|
||
If there's anything else, let me know.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 13•12 years ago
|
||
The updated compatibility bump message was sent earlier today.
Updated•8 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•