The whitelisting function thisTestLeaksUncaughtRejectionsAndShouldBeFixed was replaced by expectUncaughtRejection, and existing calls did not take effect anymore.
MozReview-Commit-ID: 3uOxkgWYWEz
--HG--
extra : rebase_source : 5a10a3ebbfe0ce2a801330041f95447c313a9a70
extra : source : 6f0394b523a66dab444b8551deb8f3c6c81d8f31
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 64395c5fdf25deebd60dfbf2cf5df3cbf7ca8abb
extra : amend_source : 0a3f13419c050662680f2bd110d724b3bf991732
extra : source : 8d53be05afc59519c5ce8cfae96d284a972fda71
The whitelisting function thisTestLeaksUncaughtRejectionsAndShouldBeFixed was replaced by expectUncaughtRejection, and existing calls did not take effect anymore.
MozReview-Commit-ID: 3uOxkgWYWEz
--HG--
extra : rebase_source : 3a7720091180a770b32b595f8094c0d20170166d
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 59e5b84cb431f3ca28287d30a3da8fbea1363ec5
Currently doesn't handle zooms or transforms, or rounded corners for inset().
MozReview-Commit-ID: J9ZTjhn9Ki0
--HG--
extra : rebase_source : 62a8952fe18e1493ba9f31e85a4d9bc7d558167c
Actually, other browsers (except to Gecko) doesn't create undo history by input.value setter. It only creates user interaction.
devtools tests check enableUndo after using input.value setter. So we should use setUserInput to emulate input instead.
Although input.value setter doesn't generate input event, but setUserInput will generate input event, so we need wait for search request on browser_inspector_search-filter_context-menu.js.
MozReview-Commit-ID: KLiv1J0i5tJ
--HG--
extra : rebase_source : d964688255177cdde165a95b34986aba8e5ad2db
Added gDevTools.getTheme() to provide the theme name, and a gDevTools "theme-changed"
event to provide a notification when the theme is changed.
MozReview-Commit-ID: EeUAmtyPpUy
--HG--
extra : rebase_source : 38515c6fb4d4294aa20d862da0c1bb96f17cd99a
Added : and ; characters to the DOM directly, visually hidden so they
won't appear but will be part of the copied text.
Changed divs to spans to make sure we don't have extra line breaks.
And simplified the logic in copySelection as a result.
MozReview-Commit-ID: EMVXAtv7EOo
--HG--
extra : rebase_source : 9f8ec82da1d873054935bd8bbf385487f5e470ac
about:debugging is requiring some unused files at the moment and they can safely be removed
MozReview-Commit-ID: Fkssj8aKMsO
--HG--
extra : rebase_source : db53346f921ec964b0f21b859f4c10dca3013062
The shared Frame component appears to set the containing element to be a
flex component, while the table view with the dominators expects an
inline-block element. This appears to have been broken for quite
some time with Bug 1251033.
MozReview-Commit-ID: CYkps6QfTJc
--HG--
extra : rebase_source : 4924f1cb0616adc40c9730205b2e5c3a4f9ceee9
In the Bug 1335055, accessibility features were added for re-focusing on
a TreeNode when it was unmounted. Unfortunately this is incompatible
with how the Tree provides a virtualized view, where it only has DOM
nodes on the page that will be visibile when things are scrolled. So
when a view is scrolled down, the TreeNode components get unmounted.
The focused node is still technically focused, but the actual component
is no longer mounted and present on the page. This causes the focus to
incorrectly jump around as the user scrolls down the page.
MozReview-Commit-ID: 64hlwCax0Ej
--HG--
extra : rebase_source : 60ba0ac37fc61bb3fc874230cc54e6147bd1b13b
Since the FilterButton component is now only a function that returns a React Element,
it looks like Enzyme can't do the comparison we were doing before.
Checking directly the resulting html, even if non-optimal, fixes the test.
MozReview-Commit-ID: 5fAk8WyYCaF
--HG--
extra : rebase_source : 9f15782b64657eb6a31eefcabbcf9775d706cc07
Since the FilterButton component is now only a function that returns a React Element,
it looks like Enzyme can't do the comparison we were doing before.
Checking directly the resulting html, even if non-optimal, fixes the test.
MozReview-Commit-ID: 5fAk8WyYCaF
--HG--
extra : rebase_source : bcf5950bbf2fb63c0a2ff1a99f578eea99379745
Removed obsolete browser_dbg_event-listeners-03/4.js tests (they are for the
old debugger, and the new debugger doesn't even support event listeners
yet, so no use keeping this test around).
Removed getBrowserForTab SDK dependency from command-state.js.
Changed the implementation of addTab/removeTab in perf test's tab-utils
helper.
MozReview-Commit-ID: 7EXJ5K3kaJm
--HG--
extra : rebase_source : 5b235deb65ede4a15d3f189d95c4a81f385185a9
Removed obsolete browser_dbg_event-listeners-03/4.js tests (they are for the
old debugger, and the new debugger doesn't even support event listeners
yet, so no use keeping this test around).
Removed getBrowserForTab SDK dependency from command-state.js.
Changed the implementation of addTab/removeTab in perf test's tab-utils
helper.
MozReview-Commit-ID: 7EXJ5K3kaJm
--HG--
extra : rebase_source : 1922ba94fe72d3d10e6a4d8a9769cf475b9f113d
DevTools are moving out of mozilla central, and since this test is relying on scratchpad
being available, it would probably make sense to move it to the scratchpad test suite
which will still be run in the new devtools continuous integration setup.
MozReview-Commit-ID: 19x6Ccp85ND
--HG--
rename : browser/components/sessionstore/test/browser_644409-scratchpads.js => devtools/client/scratchpad/test/browser_scratchpad_sessions.js
extra : rebase_source : bf564025199748b43ef56333f5c5626b266be1ca
AFAICT SimpleTest.registerCleanup is never called here. And it introduced a leak
in the session scratchpad test I want to move to this test suite. I couldn't really
understand where the leak was coming from, but using registerCleanup (which _is_
called) fixes it.
MozReview-Commit-ID: 2VE7wHxy066
--HG--
extra : rebase_source : b2e7f62a727535912be55c68d6f8b0932e9f1414
nsIPrefBranch getters support an optional default parameter.
If provided, the getter should not throw in case the pref is not defined, but
instead should return the default value.
MozReview-Commit-ID: FfWPmOC6bFI
--HG--
extra : rebase_source : a18d53c897bb7483997ed9e2faa9e737b4c644e8
This patch applies all the changes needed to the devtools actors
and the toolbox-process-window, to be able to debug a webextension
running in an extension child process (as well as a webextension
running in the main process).
The devtools actor used to debug a webextension is splitted into
3 actors:
- the WebExtensionActor is the actor that is created when the
"root.listTabs" RDP request is received, it provides the addon
metadata (name, icon and addon id) and two RDP methods:
- reload: used to reload the addon (e.g. from the "about:debugging#addons" page)
- connectAddonDebuggingActor: which provides the actorID of the actor
that is connected to the process where the extension is running
(used by toolbox-process-window.js to connect the toolbox to the needed
devtools actors, e.g. console, inspector etc.)
- the WebExtensionParentActor is the actor that connects to the
process where the extension is running and ensures that a
WebExtensionChildActor instance is created and connected
(this actor is only the entrypoint to reach the WebExtensionChildActor,
and so it does not provide any RDP request on its own, it only connect
itself to its child counterpart and then it returns the RDP "form" of
the child actor, and the client is then connected directly to the
child actor)
- the WebExtensionChildActor is the actor that is running in the same
process of the target extension, and it provides the same requestTypes
of a tab actor.
By splitting the WebExtensionActor from the WebExtensionParentActor, we are
able to prevent the RemoteDebuggingServer to connect (and create
instances of the WebExtensionChildActor) for every addon listed by
a root.listAddons() request.
MozReview-Commit-ID: L1vxhA6xQkD
--HG--
extra : rebase_source : f9438b4a9842c1dd504edf2fcd87857c670f411f
This patch applies all the changes needed to the devtools actors
and the toolbox-process-window, to be able to debug a webextension
running in an extension child process (as well as a webextension
running in the main process).
The devtools actor used to debug a webextension is splitted into
3 actors:
- the WebExtensionActor is the actor that is created when the
"root.listTabs" RDP request is received, it provides the addon
metadata (name, icon and addon id) and two RDP methods:
- reload: used to reload the addon (e.g. from the "about:debugging#addons" page)
- connectAddonDebuggingActor: which provides the actorID of the actor
that is connected to the process where the extension is running
(used by toolbox-process-window.js to connect the toolbox to the needed
devtools actors, e.g. console, inspector etc.)
- the WebExtensionParentActor is the actor that connects to the
process where the extension is running and ensures that a
WebExtensionChildActor instance is created and connected
(this actor is only the entrypoint to reach the WebExtensionChildActor,
and so it does not provide any RDP request on its own, it only connect
itself to its child counterpart and then it returns the RDP "form" of
the child actor, and the client is then connected directly to the
child actor)
- the WebExtensionChildActor is the actor that is running in the same
process of the target extension, and it provides the same requestTypes
of a tab actor.
By splitting the WebExtensionActor from the WebExtensionParentActor, we are
able to prevent the RemoteDebuggingServer to connect (and create
instances of the WebExtensionChildActor) for every addon listed by
a root.listAddons() request.
MozReview-Commit-ID: L1vxhA6xQkD
--HG--
extra : rebase_source : 7ed7735084d9351ff32ab1ad822e53dd0828dace
This was working around some old XUL layout weirdness, but nowadays this uses the same scroll frame implementation as HTML and tabStrip.scrollPosition + tabStrip.scrollClientSize > tabStrip.scrollSize cannot be true.
MozReview-Commit-ID: F5fOEpXn8ay
--HG--
extra : rebase_source : 5dcd0282e1054aad1c1a4946dd98dc33549bd2d6
The current way to configure compare-locales has a lot of
assumptions that make our l10n system really stubborn.
The generic configuration is independent of python, and uses
toml files for configuration. They're still modular, but
there's only one file format.
See http://moz-l10n-config.readthedocs.io/en/latest/fileformat.html
for the specification.
Also fixes a few nits in filter.py, where we compared the
entity key as bool, which is false if we pass in ''.
Explicitly compare as "entity is None" to be precise about
when we're checking files.
MozReview-Commit-ID: 5TmfobaImF4
--HG--
extra : rebase_source : 7c6feee0aa178315cc69fd6e8c7938365193224c
Now that we are not re-rendering the grid outline all the time, it
seems safe to change the throttling mechanism of the cell highlighting.
Instead, we use debouncing now, so that rapid movements won't lead to
useless highlighting. The cell will get highlighted only if the user
settles on a cell in the outline.
Also, we can make the timeout much shorter so that only really rapid
movements are ignored, and the rest leads to cell highlighting, resulting
in a smoother UX.
MozReview-Commit-ID: 5WxAQRaLJkC
--HG--
extra : rebase_source : 950c2945f3fb53bf7e89d25d77df9e50a3d15b85
Made the GridOutline component work with only 1 grid at a time.
It already did, but in a not so obvious way.
Removed the setState that happened during the render call to avoid
React warnings.
Cleaned up various data attribute to use the dataset property instead.
Removed the mouseover/out that controled the background color of the
highlighted cells. This now happens in CSS :hover, using currentColor.
Avoided React warnings related to missing "key" props.
Made changes to grid-inspector to avoid loops of re-renders when the
highlighter would highlight a cell on hover.
The component would wait for highlighter's events to dispatch store
actions. Instead, we dispatch them first, then when the events come, we
check if things have really changed! This way, the events will still have
effect if they come from the rule-view for instance, but not if they
come from the grid outline itself.
MozReview-Commit-ID: 6LK8B1P8iMU
--HG--
extra : rebase_source : 473ca1e1777d4e14f4f45a0b306b8153775cb1e6
Carsten "Tomcat" Book
Ryan VanderMeulen
Ben Kelly
Julian Descottes
Mike de Boer
Alexandre Poirot
Vangelis Katsikaros
Matt R
Tom Tromey
Micah Tigley
Gabriel Luong
Phil Ringnalda
Paolo Amadini
Sebastian Hengst
Patrick Brosset
Jason Laster
Oriol
Mike Park
Makoto Kato
Honza Bambas
Bob Silverberg
Nicolas B. Pierron
Brian Grinstead
Mark Striemer
Ricky Chien
Jan Odvarko
Greg Tatum
Michael Kohler
Daisuke Akatsuka
Nicolas Chevobbe
Iris Hsiao
Wes Kocher
Mats Palmgren
Ruturaj K. Vartak
Andrew McCreight
Matteo Ferretti
Tim Nguyen
Christoph Kerschbaumer
Nazım Can Altınova
Luca Greco
Dão Gottwald
Michael Ratcliffe
Axel Hecht
Joel Maher
Mark Banner