We must close cache iterators before shutting down CacheIndex because they hold reference to CacheIndex which causes that CacheIndex is not destroyed when it's dereferenced in CacheIndex::Shutdown.
--HG--
extra : amend_source : d74243f4eb4f4073ecc72ac9b331091456a91504
The original logic I wrote had the condition backwards.
MozReview-Commit-ID: IFIS8vZLgd4
--HG--
extra : rebase_source : 9f9baeb2f6284c551fb63f139d6f5942569890fd
This demotes a MOZ_RELEASE_ASSERT in the SAB case for SC write to a
run-time check. The reason is that the clone policy must conform to
the clone scope, specifically, if the scope is DifferentProcess then
the policy must deny SAB.
The check was an assert previously because we mistakenly thought that
we controlled all the callers, but we do not - the TestingFunction
serialize() has a permissive API and instead of adding a lot of
complexity there we should change the assert to a run-time check. The
code is more resilient as a result anyway.
Also document this quirk in the SC header file.
--HG--
extra : rebase_source : 4b632fe57bc9ebf3f38210b1ffad11fde57befa6
Including ARM64 implementations here because they are easy, and will be
needed by the Wasm baseline compiler anyway.
--HG--
extra : rebase_source : 5baab6faed8fcd4c5b661e40ac011da051573a0a
extra : intermediate-source : 6d7fa52e38fbd7f9d106b8bbacca51d3907bd4f7
extra : source : 724822b1b806b8f7ce6af0d3891be1e4a450ffe9
Including ARM64 stubs here because it simplifies code in the Wasm
baseline compiler, and doesn't hurt.
--HG--
extra : rebase_source : 58933b501248f2f53cb88117f93662f1ae3f9bfe
extra : source : f217aeea295bac03a323917292560ba1f491b0fb
- Work-around in browser_ext_menus_events.js for bug 1428213
- Fix indentation issues (eslint)
- Hide the "pageUrl" property for bookmark menu events
(fixes test failure in test_bookmark_contextmenu).
MozReview-Commit-ID: 4YHJci0J7Rh
--HG--
extra : rebase_source : 3879e843bd2826fcd34dbd41708d570024e681e8
This removes the gyp files to build webrtc. It looks like part of Bug 1371485 is
to vendor gyp elsewhere in tree at which time we can complete cleaning this up.
MozReview-Commit-ID: 8MqatafniN5
--HG--
extra : rebase_source : 1cf7a41f0b8a1a95dc008f4a39536ee7e76027c4
We extract the ARM disassembler bits and place them in
jit/shared/Disassembler-shared.{cpp,h}, and then clean them up and
generalize them. The ARM assembler is slightly modified to deal with
this but the changes are local.
We then add code to the ARM64 assembler to drive the disassembler.
The structure is as for the ARM disassembler.
--HG--
extra : rebase_source : 7197ec8b3b8985005efb7522b6719140b2eac5e4
extra : source : aa8517d9efb1aa89f4661bdb095d5a0f526cb652
This adds support for detecting globals created by these helpers, as well as a
rule to enforce their use over the older XPConnect variants.
The latter rule also supports fixing code to use the newer variants, and will
be used in the next part to rewrite in-tree ESLint-enabled code that fails it.
MozReview-Commit-ID: 6Bgo6ohQA5j
--HG--
extra : rebase_source : feca0a0ed339420ea19faa1f6614e6253f0c840e
extra : absorb_source : d32d3d23fbd2c7dcae082375a1f9a61766b04b75
extra : histedit_source : 83cebb4f3eb66a79d38ee5412a5739d0c603425b
This is necessary before we enable the ESLint rule to require using
ChromeUtils for module imports rather than older methods.
MozReview-Commit-ID: mKqByUS0o2
--HG--
extra : rebase_source : d4b856aac7ff7eddc37cbf591c4e6522c45453e2
extra : histedit_source : 1ca2b6031e480fb44a15991241901224acc9e52f
This helper makes it easy to lazily import a JavaScript module the first time
one of its exports is required. It is intended to replace
XPCOMUtils.defineLazyModuleGetter, which has similar functionality but is much
less efficient.
MozReview-Commit-ID: 2zxXYwrn3Dr
--HG--
extra : rebase_source : 998de7388ee03fdec0a0949b4e43bd9169dbb592
extra : histedit_source : 414d0ed1842b2270146d37b2788a56c682d3d695
Looking up and copying exported properties each time a module is loaded is
fairly expensive at the best of times. It's even more expensive when we only
want to export a subset of symbols, which generally requires creating a
temporary object to hold the exports, or fetching them directly from the
returned global.
Aside from making the general case a bit faster, storing exports on an object
allows us to optimize lazy module imports by fetching imported symbols
directly from the exports object with very little additional overhead.
MozReview-Commit-ID: C9PGoXPNmsh
--HG--
extra : rebase_source : 6232cf7a52fd69ebeb8b6e39680646f287c272a8
extra : histedit_source : b223c73a6e9092491f4fb09f8c795f5aa4b43df3
The shutdown path has a way to free the sObjectMap before all plugin references to it have been executed. It does this by scheduling a DeferNPObjectReleaseRunnable, then shutting down the plugin with PluginInstanceChild::Destroy. This patch keeps the runnable from failing in that case.
This test ensures that the menu events will always be fired in the
natural event order.
Two menus are tested:
- A context menu in the page.
- The tools menu.
MozReview-Commit-ID: 4sLyvgMYMtE
--HG--
extra : rebase_source : 9837661f034530b63c9cbbbb3104fb6367f513a8
This commit lifts the restriction that onShown is only fired for
extensions with a visible menu item.
MozReview-Commit-ID: Ao4MgBoRWLR
--HG--
extra : rebase_source : c1acd1bcbfdcc6ef4bfaf199f3f016dde71ad2e5
The logic in onClicked had some flaws:
- editable can be undefined instead of a boolean.
- linkText, linkUrl is set in non-link contexts.
- srcUrl is set even in non-media contexts.
This change does not add new tests, because test coverage for the
event data generator is provided by:
browser/components/extensions/test/browser/browser_ext_menus_events.js
There is one observable change here.
Previously, linkUrl and linkText would also be set for non-link context
if the selected text contained a URL. When this happens, then
nsContextMenu.js sets onPlainTextLink=true.
With this refactor, linkText and linkUrl are only set if the context is
"link" (onLink=true).
MozReview-Commit-ID: 2xf1F41bn0U
--HG--
extra : rebase_source : 698e0b9a2eb10f58d02e062f930753752aff9a54
- Adds most of the OnClickData properties to the onShown event parameter
(except for menu-specific properties such as parentMenuId / checked).
- Add tests to verify the values of these properties.
MozReview-Commit-ID: 7705sJyAOIJ
--HG--
extra : rebase_source : 8948ea20129cfd1c34653a3cbe9b36cebd6fa00d
Together with the previous patches that introduced menus.onShown,
this enabled extensions to update/remove menu items after a menu
has been shown.
At this point, it is not yet possible to add a menu item if an
extension has not shown a menu item before; this can be added later.
MozReview-Commit-ID: E0JrE9gd4gS
--HG--
extra : rebase_source : 0d21c369eb17b3a819603f27af8d9f9fccf5b783
Splot gMenuBuilder.build in three separate functions because the
individual functionality is needed later.
This is just moving some code around, nothing interesting to see.
MozReview-Commit-ID: Lo6QmLQBtO5
--HG--
extra : rebase_source : 6476a8834c378d6fa059fab1a5f2323f82688658
Previously, there was no guarantee for the uniqueness of the ID.
Now the ID is unique, and always set.
See https://bugzil.la/1358213#c6 and #c7 for examples of collisions.
MozReview-Commit-ID: 7CHP6tWFDUg
--HG--
extra : rebase_source : a585dcfd3a83eb590de9b69a02dba8b4bb1b0a0c
This commit adds the bare minimum to support the onShown and onHidden
methods in the contextMenus and menus API (plus tests).
The onShown event data may be extended in a separate commit, to make it
easier to see how the additional properties are reflected in the tests.
MozReview-Commit-ID: 20VJS2YLhTN
--HG--
extra : rebase_source : 1fe9985b2e5daa1be455e07ccf58e36e6d9fe508
Most close*Menu methods in browser tests allow itemToSelect to be null.
Some did not.
Now they do (after this commit)
MozReview-Commit-ID: 2jSGAi2R3ZD
--HG--
extra : rebase_source : 897d4a66f5b1da8027180f85c5f5f5284734e860
Here, in the case of a MESSAGES_ADD action, we clone the state before
calling addMessage. Then, in addMessage, we can mutate the cloned state.
This saves a lot of time since we don't have to re-create a new state
for each message.
MozReview-Commit-ID: GDBFBytKp5u
--HG--
extra : rebase_source : bfa8252b3dc2e191fa83cd2ad8cb60ab8bb77366
Some methods in HTMLEditor uses NS_IMETHOD that doesn't override. So we should
replace with nsresult to avoid virtual method.
MozReview-Commit-ID: 7LillLQNhlg
--HG--
extra : rebase_source : 02655cdcf9350caae1fd12dfeb038f82f74aa0f0
First attempt at https://github.com/servo/servo/issues/874
Source-Repo: https://github.com/servo/servo
Source-Revision: 9c1307307575637f5ad360413c6a8395579ab511
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 99d0f27c586a537f25a5285ed4447fc09e5de430
Now, nobody implements nsIEditorObserver::BeforeEditAction() and
nsIEditorObserver::CancelEditAction(). So, we can remove them.
MozReview-Commit-ID: DYppLayC5oT
--HG--
extra : rebase_source : 196e042234c65a43947a1aa90898901389a3a53b
Similar to TextInputListener, EditorBase should store IMEContentObserver
directly instead of via nsIEditorObserver. Then,
EditorBase::NotifyEditorObservers() can call each method directly.
Additionally, we can make IMEContentObserver not derived from nsIEditorObserver.
MozReview-Commit-ID: cNKWJe5eUC
--HG--
extra : rebase_source : 4ed3b3b3180b8ee4a7c514ce1f89eba4dad64fbe
Now, EditorBase can store TextInputListener directly instead of as
nsIEditorObserver. And then, EditorBase can call its EditAction() method
directly. Therefore, we can make TextInputListener not derived from
nsIEditorObserver.
MozReview-Commit-ID: 4qPnnvReLKy
--HG--
extra : rebase_source : cde47e245c9856abf696dbaf8e26d8e4d6d98d42
EditorBase needs to access nsTextInputListener directly for saving runtime
cost of EditorBase::NotifyEditorObservers(). Therefore, it should be
exposed as "mozilla/TextInputLitener.h".
This patch rename it to mozilla::TextInputListener too.
MozReview-Commit-ID: 6PMzNWfTIHW
--HG--
rename : dom/html/nsTextEditorState.cpp => dom/html/TextInputListener.h
extra : rebase_source : 43c685a8f4c023c62bea26b3bf55b4f728ab438e
Spec bug: https://github.com/w3c/editing/issues/172
Inline elements in paragraph except anchor elements which have non-empty
href attribute should be created in new paragraph even when new ones are
empty because users must expect to keep writing some text with same style,
but for anchor elements with non-empty href attribute, users must not
expect to create same link in new paragraph in most cases.
MozReview-Commit-ID: KjpOzfv4F0j
--HG--
extra : rebase_source : ad50d4906dd8032a7f5c3a5efb0ce98942485743
