In preferences tests, all calls to waitForEvent function defined in
browser/components/preferences/in-content/tests/head.js has been replaced with
calls to BrowserTestUtils.waitForEvent.
MozReview-Commit-ID: IrtGJFtWPPj
--HG--
extra : rebase_source : 4098e79c532e57acc2d6e48ae496be1d0e6a9f9f
A significant chunk of migration jank that I observe locally
happens due to login encryption. This patch reduces the locally
observed jank (measured importing 100 logins) from 180ms to 25ms.
Try is green, and as far as I can tell I don't see any thread
safety issues, but I'm not 100% sure on that. I don't see any
red flags inside the SecretDecoderRing::Encrypt implementation.
I only moved Chrome logins over since I wanted to frontload any
potential issues with the whole approach. It shouldn't be too
hard to move the MSMigrationUtils and IEProfileMigrator uses
over though.
MozReview-Commit-ID: 75edUqJlk8x
--HG--
extra : rebase_source : 0a8e16c46e05972fb01c9703b52cdb5755b0b40b
There are still known issues with the browser chrome when emulating, but this changeset is
done in service of getting the UI to be close enough to start running Talos tests against
it in Bug 1425330.
MozReview-Commit-ID: B0w1aOmi4FJ
--HG--
extra : rebase_source : e8b13f9203f0e368fb6f36bc9d2059fff7061b54
This is a short-term solution to our inability to apply CSP to
chrome-privileged documents.
Ideally, we should be preventing all inline script execution in
chrome-privileged documents, since the reprecussions of XSS in chrome
documents are much worse than in content documents. Unfortunately, that's not
possible in the near term because a) we don't support CSP in system principal
documents at all, and b) we rely heavily on inline JS in our static XUL.
This stop-gap solution at least prevents some of the most common vectors of
XSS attack, by automatically sanitizing any HTML fragment created for a
chrome-privileged document.
MozReview-Commit-ID: 5w17celRFr
--HG--
extra : rebase_source : 1c0a1448a06d5b65e548d9f5362d06cc6d865dbe
extra : amend_source : 7184593019f238b86fd1e261941d8e8286fa4006
This allows removing the separate keyboard navigation map.
MozReview-Commit-ID: 2N0wflAvg7Y
--HG--
extra : rebase_source : 63b9ae6e4db0de1957cb011c69134894d311b703
Only one method is moved to the PanelView class to simplify the keyboard navigation test.
MozReview-Commit-ID: CHB5FiT9ptn
--HG--
extra : rebase_source : ec588beae9f1208a37ce85f9d28029dfd979db24
This makes the code easier to follow and facilitates future refactoring, for example the set of known views can be removed entirely by making the clean up and navigation code use the stack of open views.
The SlidingPanelView class can thus be removed, saving various lines of code. The class implemented a small optimization for garbage collection, that was already less effective because various other objects are created during each view transition anyways.
MozReview-Commit-ID: Z4JJMklUMf
--HG--
extra : rebase_source : 8789a35c4234fc691c62efeb3445b776b14fc1f9
The setMainView method of PanelMultiView controls the "mainview" attribute, which is already set or removed later in the showSubView method. When called at construction time, it changes the mainViewId if there is at least one child in the "panelmultiview" element and the original mainViewId does not already reference the first child. This would be incorrect, but in practice it never happens for either ephemeral or static panels, and can be avoided for the throw-away activated page action panel.
The setMainView method of PanelUI is never called, and this makes the corresponding PanelMultiView method removable.
MozReview-Commit-ID: 5bNidHfKFTA
--HG--
extra : rebase_source : b527827d30d682d183981347c2caf3a8a5d81355
Commands started from an activated action panel should not be anchored to the main button, and regression tests should simulate the case where both the main action panel and the individual action button are visible and the action is invoked from the main action panel.
MozReview-Commit-ID: Eg1wP2rRe2d
--HG--
extra : rebase_source : 6caac7368c85195c91066c6a61d3043a9fbc770f
- 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 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
