We used to read the contents of the clipboard to tell if paste was enabled,
that unfortunately means updating commands was extremely slow for large
clipboard data.
After this change we only check the data flavors. This means paste will be
enabled more often, even for unsupported strings, but commands updating will
be much faster. Places updates commands often, so this is quite useful.
Differential Revision: https://phabricator.services.mozilla.com/D75202
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
- Unified openContainerNodeInTabs and openURINodesInTabs in PlacesUIUtils into openMultipleLinksInTabs
- Users are now warned when the amount of links to be opened is equal to or exceeds browser.tabs.maxOpenBeforeWarn
Differential Revision: https://phabricator.services.mozilla.com/D12983
--HG--
extra : moz-landing-system : lando
- Unified openContainerNodeInTabs and openURINodesInTabs in PlacesUIUtils into openMultipleLinksInTabs
- Users are now warned when the amount of links to be opened is equal to or exceeds browser.tabs.maxOpenBeforeWarn
Differential Revision: https://phabricator.services.mozilla.com/D12983
--HG--
extra : moz-landing-system : lando
This allows the JS to work in HTML documents, where whitespace is preserved. In XUL
documents, whitespace is ignored when parsing so text nodes are generally not returned.
The following changes were made, with manual cleanups as necessary (i.e. when firstChild actually
refers to a text node, or when firstChild is used in a loop to empty out an element):
firstChild->firstElementChild
lastChild->lastElementChild
nextSibling->nextElementSibling
previousSibling->previousElementSibling
childNodes->children
MozReview-Commit-ID: 95NQ8syBhYw
--HG--
extra : rebase_source : 186d805f7a2a56694dda9032aceac2dfe5424753
The tagging API is being merged into the bookmarking API. This is part of it.
Differential Revision: https://phabricator.services.mozilla.com/D2450
--HG--
extra : moz-landing-system : lando
This removes the bookmark description UI, but leaves the backend in-place for a release or two, so that users have time to save anything they want (e.g. via backup).
The backend will be removed in bug 1402890.
MozReview-Commit-ID: La4AYFar7eK
--HG--
extra : rebase_source : 02bfe3cacdac331d09d5e62a1a70f48b68741670
Fix the ownership check to correctly check if we're cutting or copying.
MozReview-Commit-ID: 1eLt4Fyy2nE
--HG--
extra : rebase_source : 78850cde9d4433d844bef32b6624331460663025
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
test_419731.js can be removed since it is already covered by browser_bookmarkProperties_editTagContainer.js
MozReview-Commit-ID: K0LFuTptWyW
--HG--
extra : rebase_source : 10066aa0bdb6a598fc6af638fed455d58422b7fb
The overlay was responsible for script loading and defining three elements
(bhTooltip, placesCommands, placesContext). In the majority of places where
the overlay was included only part of it was used. To remove the overlay, the
elements were each split into include files and moved into where they
were used. For the scripts, a JS file was added that defines all the lazy
modules and then this script, globalOverlay.js and utilityOverlay.js were
inlined to everywhere that would have included them from the overlay.
MozReview-Commit-ID: 8T5D46oYWLn
--HG--
rename : browser/components/places/content/placesOverlay.xul => browser/components/places/content/placesCommands.inc.xul
rename : browser/components/places/content/placesOverlay.xul => browser/components/places/content/placesContextMenu.inc.xul
extra : rebase_source : c1071af4ea264a95183cbc65caae98feb23d58e5
console.assert keeps the same semantics as NS_ASSERT in that it doesn't throw an exception,
but a lot of the places code was using it in a way that would be better served by throwing
an exception when the condition is false.
MozReview-Commit-ID: DEF5HSfYO36
