This pref was removed in bug 1387081, when the sidebar-button started to
be shown by default. I have also removed the end of the test that
removed the button, since these were attempts to restore the default
state. At the inception of the tests, the default state is to not show
the button, but now the button is to be shown by default.
Differential Revision: https://phabricator.services.mozilla.com/D2954
--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
Likely fixed by the patch for bug 1417052
Ran the test with --repeat=50 on Linux and did not observe any failures.
MozReview-Commit-ID: FuMo8jdgJCn
--HG--
extra : rebase_source : 2a296cc7817607d352bc56b5b200da81d3e26bf0
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 : source : 1070e943ab79f6c46fd6518bc3695b1bee3dfd48
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 : source : ef15c7fe957fd48be8a963ab16ddd5a172fe987d
This removes the requirement for browser-style checkboxes and radio buttons
to be followed by a label since the reason why this was originally done
no longer applies because bug 418833 made it possible for checkboxes and radio
buttons to handle styling themselves rather than requiring a label::before
element.
--HG--
extra : rebase_source : 61957bd667b509e8769b86de7f783472d801bb0f
This ensures that the check that was introduced by bug 1370499 still
continues to work even though it was refactored by the previous commit.
MozReview-Commit-ID: GdbIPA6vxIB
--HG--
extra : rebase_source : 9246a1d6855de45eca8de5ee806d3a3e5ab7f0be
Manually verified using the STR from
https://bugzilla.mozilla.org/show_bug.cgi?id=1417052#c47
I am not re-enabling the test by default because the same test file is
reported to have another intermittent (bug 1416103).
MozReview-Commit-ID: 1xsyjMMby1H
--HG--
extra : rebase_source : 67080c8d7d7d804bf66aa40b577486c68dcaeb4b
And re-enable the test_ext_all_apis.html test to ensure that new APIs
are only available by default if the contributor really intents to.
MozReview-Commit-ID: FWIKybrk0EE
--HG--
extra : rebase_source : 58c5bd98ddb59be74b9454995cbbd3edef6c45f9
The hard-coded wait exists to avoid a test failure caused by a
non-functional click event in an options browser. However, that
still does not get rid of the intermittent failure.
To really avoid the timing issue, check whether onclick was fired
after supposedly triggering a click, and if not, wait and retry.
MozReview-Commit-ID: 9eg6sz1s1e3
--HG--
extra : rebase_source : 8945f2597beb99e9c5d03c08bc054692960e6281
Re-enable the test that was disabled in bug 1381305 and fix the
underlying issue that caused th intermittent failure in the first place.
MozReview-Commit-ID: BL9wS2fogaf
--HG--
extra : rebase_source : 685f43b2e47d80f71814385a5c8b94fd3000eac9
Re-enable the test that was disabled in bug 1381305 and fix the
underlying issue that caused th intermittent failure in the first place.
MozReview-Commit-ID: BL9wS2fogaf
--HG--
extra : rebase_source : 685f43b2e47d80f71814385a5c8b94fd3000eac9
This ensures that the check that was introduced by bug 1370499 still
continues to work even though it was refactored by the previous commit.
MozReview-Commit-ID: GdbIPA6vxIB
--HG--
extra : rebase_source : 9246a1d6855de45eca8de5ee806d3a3e5ab7f0be
Re-enable the test that was disabled in bug 1381305 and fix the
underlying issue that caused th intermittent failure in the first place.
MozReview-Commit-ID: BL9wS2fogaf
--HG--
extra : rebase_source : 685f43b2e47d80f71814385a5c8b94fd3000eac9
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
Use sendMessage/awaitMessage instead of notifyPass/awaitFinish in tests
where this is not the last completion callback.
Remove an unneeded browser.contextMenus.onClicked.addListener call.
MozReview-Commit-ID: Akpla9tiAlD
--HG--
extra : rebase_source : 483acb2fd27f06c163871fa61c660ed5c2f15050
browser.menus.create and browser.contextMenus.create are asynchronous
APIs. For compatibility reasons, they cannot return a promise (since
they already return an integer).
This modifies all tests that use either of these APIs, to ensure that
the test waits for the callback of the last menus/contextMenus.create
call before continuing with the test.
In some cases in browser_ext_menus.js I did not add any callbacks,
because there were other asynchronous API calls (browser.tabs API)
that already guaranteed that the test made a round-trip to the parent
process before continuing.
This fixes:
- Bug 1462862 (browser_ext_contextMenus_icons.js)
- Bug 1403429 (browser_ext_contextMenus_onclick.js)
- Bug 1321182 (browser_ext_contextMenus.js)
- Bug 1373234 (browser_ext_menus.js)
MozReview-Commit-ID: IZFUyIw8Tbl
--HG--
extra : rebase_source : 4f28acf0189b4b93808b13200cf966a04873bf78
Before this change, we accessed the browser URL in the following ways:
- "chrome://browser/content/browser.xul"
- "chrome://browser/content/" (which redirects to chrome://browser/content/browser.xul)
- Services.prefs.getCharPref("browser.chromeURL") which returns "chrome://browser/content/"
- getBrowserURL() from utilityOverlay.js
MozReview-Commit-ID: I5vtRke1x9t
--HG--
extra : rebase_source : c525350a1954740873e85b045cbb14a8b43aa89d
We don't intend to ship this in the near future until the integration with
AnimationWorklet is clear (although we might ship a read-only version).
That said, we use this feature extensively internally (e.g. in DevTools etc.) so
we enable this feature for system callers.
MozReview-Commit-ID: AhB7ZmU1Xzw
--HG--
extra : rebase_source : 630d7dc56b44a9261bb34aa5417cb9b7050efba4
So panels provided by extensions with IDs that contain words like "inspector"
don't break.
Include test in existing panel creation test.
MozReview-Commit-ID: JerMCaKRgkl
--HG--
extra : rebase_source : 56c0262597c4070c7e16b32ebf824ef1fdd1fd8d
So panels provided by extensions with IDs that contain words like "inspector"
don't break.
Include test in existing panel creation test.
MozReview-Commit-ID: JerMCaKRgkl
--HG--
extra : rebase_source : 59a884cb616e22e3c6062d19d223b5670cf17225
Also change PlacesUtils.history.removeVisitsByFilter to be able to remove by transition type.
MozReview-Commit-ID: Bkiv0ScUi07
Differential Revision: https://phabricator.services.mozilla.com/D2056
--HG--
rename : toolkit/components/places/tests/unit/test_download_history.js => toolkit/components/places/tests/history/test_download_history.js
extra : moz-landing-system : lando
Also changes the tooltip on the home button to be independent of the URLs
it opens, per dolske.
Some tests explicitly set browser.startup.homepage, but only through
SpecialPowers.putPrefEnv. That's a good compromise, given the extra
functionality there.
MozReview-Commit-ID: FPLxzi3jQAP
--HG--
extra : rebase_source : c2b014f2fb1c78ce04859344bd1803ef48d5d68d
This allows keyboard shortcuts containing both "Ctrl" and "Alt" in the
manifest of webextensions (in the "commands" -> "suggested_key" key),
rather than just one of these modifiers. The equivalent combinations
on MacOS (any two of "Command", "Alt" and "MacCtrl") are also allowed.
Non-sensical combinations (such as "Ctrl+Command" or "Ctrl+Ctrl") are
forbidden.
MozReview-Commit-ID: 59tC2efLm5q
--HG--
extra : rebase_source : 5a9375116aab6b3c4abe96c4850e4ff857d93532
extra : intermediate-source : 507b35de0e93baccb54f83e8bce6cedfe9754dd9
extra : source : 115c5332fadc1d52940f8356f6273f0e9680657f
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
--HG--
extra : rebase_source : ef8fa174f902e6abd397fb80294e83843120aa81
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
--HG--
extra : rebase_source : fd064e53e8645c3914188c05e71c8800d6f2174b
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
--HG--
extra : rebase_source : 1190d4f127453cdcb692deb5982e92a93e236b9e
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
--HG--
extra : rebase_source : 1190d4f127453cdcb692deb5982e92a93e236b9e
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
--HG--
extra : rebase_source : 148555189f73fb29a48296215e367c406f3f0286
