This also fixes unintended behavior for which clicking the selected item in the sidebar selector would hide the sidebar.
Differential Revision: https://phabricator.services.mozilla.com/D3145
--HG--
extra : rebase_source : 891c99ab68f4689513801a1957a3d3846b7ffe58
The immediate goal is only to remove the broadcasters, so we still require the labels to be set manually on the "toolbarbutton" and "menuitem" elements. Generating these elements programmatically from the new SidebarUI.sidebars object, both for built-in sidebars and extensions, can be a future improvement.
The autoCheck attribute is also unnecessary since it is only intended for the menu items, and they are already properly updated after their command is invoked. Since the attribute was written with the wrong capitalization, it already had no effect.
The persistence of the label of the sidebar selector is also unnecessary since it is already set on startup. Removing this does not seem to cause any additional flickering.
Differential Revision: https://phabricator.services.mozilla.com/D3143
--HG--
extra : rebase_source : a5712b8e9bbdea29ab9e9a1bbd93217b24c354b4
The PageActions API is now used to assign a title to the bookmark action.
This also prevents some tooltips from being set unnecessarily on menu items.
Differential Revision: https://phabricator.services.mozilla.com/D3010
--HG--
extra : source : 9222f57d2c20b59b878660b0b998646101d70022
extra : amend_source : a160298483258a7bbd9920dd4eba9dcc43cfb4f3
This prevents the reference string attributes from being replicated unneededly.
Differential Revision: https://phabricator.services.mozilla.com/D3008
--HG--
extra : source : 99addb2df281405ebd65805884ffde95c553f6ea
The key used to be removed from the markup. This changes it to include
the <key> but instead disable it through the related command, which fits
the pattern used with other commands.
MozReview-Commit-ID: LPuwULDt22W
--HG--
extra : rebase_source : f463e41602b6c34c4cfcc2254d78647724117318
This removes the sync reflow from almost all cases. The only case where we keep it is when a keypress
caught in content triggers a sync message to the parent process. We should clean this up in bug 1371523.
I've tried to fix the tests, but a lot of them seem to be disabled anyway...
MozReview-Commit-ID: 9k36p7q8MKy
--HG--
extra : rebase_source : 311ee41ba9456a5c5d58b81a0cfa999bcef0027e
This removes the sync reflow from almost all cases. The only case where we keep it is when a keypress
caught in content triggers a sync message to the parent process. We should clean this up in bug 1371523.
I've tried to fix the tests, but a lot of them seem to be disabled anyway...
MozReview-Commit-ID: 9k36p7q8MKy
--HG--
extra : rebase_source : 311ee41ba9456a5c5d58b81a0cfa999bcef0027e
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
The overlay defined two elements (helpMenu, menu_ToolsPopup) for all
platforms and three others (windowMenu, baseMenuCommandSet, baseMenuKeyset)
that were MacOS only. The two all platform elements and windowMenu were only
used once and inlined into browser-menubar.inc. The rest of the MacOS only
elements were conditionally inlined into browser-sets.inc.
MozReview-Commit-ID: D2uyCrnepuH
--HG--
extra : rebase_source : a3f7ecaf70c55574ee87091027a651ce429c6876
The overlay elements with children of editMenuOverlay.xul are moved into
include files (editMenuCommands.inc.xul and editMenuKeys.inc.xul). For
the other single elements in the overlay, the attributes are inlined
wherever they are used.
MozReview-Commit-ID: 792cuzUvQxT
--HG--
extra : rebase_source : 58e4c05bde16cee873d37c6198de102d048499c2
The phishing overlay was only used in one place and could be inlined. This
was slightly less straightforward as the original overlay was used on
browser.xul, but the elements it overlayed are defined in include files and
in another overlay (baseMenuOverlay.xul). Since baseMenuOverlay.xul is used
by other windows, the "hidden" attribute had to be added to the phishing
menuitems so they didn't show up in the other windows e.g. places.
MozReview-Commit-ID: 6t0MpWmgyGg
Signed-off-by: Brendan Dahl <brendan.dahl@gmail.com>
--HG--
extra : rebase_source : 09a691d24cec78c72111a9d3e476c8c80e097178
Since we're not passing an optional parent folder around anymore, this patch also
removes PlacesCommandHook.bookmarkCurrentPage() in favor of a simplified
PlacesCommandHook.bookmarkPage() signature.
MozReview-Commit-ID: HmzwmATgQyw
--HG--
extra : rebase_source : 384e7dba2ab58b212273d39bf6344424a9841e4f
The only thing that I didn't remove was the process ID on the tab tooltip, which I find to be super helpful. For that, I changed the check from E10S_TESTING_ONLY to NIGHTLY_BUILD.
MozReview-Commit-ID: 2qNWebBpsMY
--HG--
extra : rebase_source : b30a4492f839186584c074b82a1969973cda48e0
The only thing that I didn't remove was the process ID on the tab tooltip, which I find to be super helpful. For that, I changed the check from E10S_TESTING_ONLY to NIGHTLY_BUILD.
MozReview-Commit-ID: 8wbjdYIC3gb
--HG--
extra : rebase_source : 2ea1b77d4a9fd9c3eb17853c8ec655b309a3fa8c
