This introduces constants for the addon states and migrates ADBAddon to a class
Differential Revision: https://phabricator.services.mozilla.com/D7881
--HG--
extra : moz-landing-system : lando
Depends on D7405. The adb-addon module fires events whenever the
addon state changes, so Devices.jsm should be able to simply reuse this
module to update its internal state, rather than having adb-addon set
something on Devices.jsm directly.
On a sidenote, we really should not propagate the adb status via Devices.jsm
but since WebIDE relies on this, I decided to keep the code as is for now.
We will remove it from Devices.jsm when WebIDE is removed.
Differential Revision: https://phabricator.services.mozilla.com/D7406
--HG--
extra : moz-landing-system : lando
Depends on D7404. The install method should not hardcode "webide"
for the addon manager telemetry info
Differential Revision: https://phabricator.services.mozilla.com/D7405
--HG--
extra : moz-landing-system : lando
Depends on D7403
The getADBAddon/forgetADBAddon is not removing listeners or doing
anything useful since the next call to getADBADdon will just recreate an
instance of ADBAddon. We can expose a singleton and use lazy requires to
achieve the same effect
Differential Revision: https://phabricator.services.mozilla.com/D7404
--HG--
extra : moz-landing-system : lando
Depends on D7402. Moving the module to a shared older. Following
patches will cleanup the implementation to remove WebIDE couplings.
Differential Revision: https://phabricator.services.mozilla.com/D7403
--HG--
rename : devtools/client/webide/modules/addons.js => devtools/shared/adb/adb-addon.js
extra : moz-landing-system : lando
Since Firefox 41 it has been possible to add a rule with a selector
which does not match an element. The checks of the existence of this
functionality are outdated and can be safely removed.
No supported old versions of Firefox make use of the previous
functionality anymore.
MozReview-Commit-ID: D5ZP09Ckeqd
Differential Revision: https://phabricator.services.mozilla.com/D7597
--HG--
extra : moz-landing-system : lando
While this is not strictly related for uninstalling ADB helper this
small cleanup avoids duplicating the declaration of the adb extension
in two different preferences.
The URL preference also moves to a devtools-shared preference as there
is not much sense to keep it webide only.
Differential Revision: https://phabricator.services.mozilla.com/D7057
--HG--
extra : moz-landing-system : lando
This patch turns the current top-level handling, which relies on
the console API to print the result of the await expression, into
something natively handled by the server.
First, we don't add a .then handler to the generated async iife by
the mapper. We also removes the case we added in the JsTerm to *not*
print the result for top-level await expression.
In order to make the server capable of handling generated async iife
caused by the mapper, we send to evaluateJsAsync the `mapped` object
that `mapExpression` returns. This way, the server can check if an
expression was originally a top-level await.
If it is the case, we get the promise from the async iife and wait for
it to settle. If it resolves, we simply return the result, as a grip,
to the client. If it rejects, we return a special packet indicating to
not print anything to the client. The error will be reported by the
engine as `uncaught exception: …`.
We add several tests and modify the existing one to make sure we handle
top level await correctly in different situation (resolving, rejecting,
when paused in the debugger, when using $_, …).
Differential Revision: https://phabricator.services.mozilla.com/D6903
--HG--
extra : moz-landing-system : lando
Summary:
create LazyActorClass based off ObservedActorFactory and RegisterdFactory classes for use in RootActor and BrowsingContextActor;
Depends on D6468
Reviewers: ochameau
Reviewed By: ochameau
Bug #: 1473513
Differential Revision: https://phabricator.services.mozilla.com/D6470
--HG--
rename : devtools/server/actors/common.js => devtools/shared/protocol/lazy-pool.js
extra : rebase_source : 09a1c8eac3cbb5856a5e3e61a1c0540efe32e5bd
This patch adds the ability to open the autocomplete popup when
typing an opening bracket (i.e. `[`]) in the console input.
This impacts a significant amount of function where we assumed
that the only way to get a completion was to use a dot.
We uses the rename `anylyzeInputString` function to get the
completion part from an input, as well as if the user is performing
an element access (i.e., using the bracket).
We then send that information to the webconsole actor, which send
it to the client.
This allows us to rely on a single parse of the input and gives us
access to this information everywhere we need to, be it on the client
or on the server.
We allow the user to type property name without quotes, and we add
them when the user accept an autocompletion.
We also automatically add a closing bracket (i.e. `]`), when it's needed.
Some test are added. On the server side to make sure the actor's autocomplete
function returns what's expected.
We take that as an opportunity to add test for commands.
On the client side, tests are added to ensure the different behavior works
as expected (check the completion text and the input after accepting
the completion when the user entered some letters, or not, with or without
quotes, with different quotes, hitting the autocomplete cache, …).
A test which accesses the autocomplete cache was modified since the shape
of the cache changed to include the last matchProp as well as the
isElementAccess boolean.
Differential Revision: https://phabricator.services.mozilla.com/D6128
--HG--
extra : moz-landing-system : lando
create LazyActorClass based off ObservedActorFactory and RegisterdFactory classes for use in RootActor and BrowsingContextActor;
Depends on D6468
Differential Revision: https://phabricator.services.mozilla.com/D6470
--HG--
rename : devtools/server/actors/common.js => devtools/shared/protocol/lazy-pool.js
extra : moz-landing-system : lando
Summary:
This method isn't specific to tabs. It can attach to any "target" actor that inherits from BrowsingContextActor.
Depends On D6161
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6162
MozReview-Commit-ID: Exz5fWyWyfN
Summary:
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6161
MozReview-Commit-ID: KmFi1LIUBga
Summary:
This method isn't specific to tabs. It can attach to any "target" actor that inherits from BrowsingContextActor.
Depends On D6161
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6162
MozReview-Commit-ID: Exz5fWyWyfN
Summary:
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6161
MozReview-Commit-ID: KmFi1LIUBga
This method isn't specific to tabs. It can attach to any "target" actor that inherits from BrowsingContextActor.
Depends On D6161
Differential Revision: https://phabricator.services.mozilla.com/D6162
--HG--
extra : moz-landing-system : lando
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Differential Revision: https://phabricator.services.mozilla.com/D6161
--HG--
extra : moz-landing-system : lando
Summary:
This method isn't specific to tabs. It can attach to any "target" actor that inherits from BrowsingContextActor.
Depends On D6161
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6162
MozReview-Commit-ID: Exz5fWyWyfN
Summary:
Now that all the "remoting" of this method has been moved to TargetFactory.createTargetForTab,
we should rename this method to what it does now. It mostly call attach requests
of the target actor and its child console actor.
It also "connect" the webextension target actor, but I would like to eventually move that
outside of TabTarget.attach, like makeRemote.
Depends On D4078
Reviewers: yulia!
Tags: #secure-revision
Bug #: 1485676
Differential Revision: https://phabricator.services.mozilla.com/D6161
MozReview-Commit-ID: KmFi1LIUBga
Summary:
The behavior the WG proposed is way more subtle than what that bug implements,
including:
* Implementing two logical overflow longhands.
* Expanding the overflow shorthand to different longhands depending on the
syntax of that.
Meanwhile, Blink hasn't done the swap and will ship the same behavior that we
shipped in Firefox 61 (bug 1453148), that is, overflow-x, then overflow-y.
So I think lacking a clear way forward we should revert this change and preserve
our shipped behavior.
Reviewers: dbaron!
Tags: #secure-revision
Bug #: 1492567
Differential Revision: https://phabricator.services.mozilla.com/D6317
nsISettingsService isn't implemented, and hasn't been for some time. This patch
removes its use, and removes all the code that depends on its presence,
including getSetting() and getWallpaper().
--HG--
extra : rebase_source : e718bd5daf03179d42f42e00a55e0bebe3a03a2d
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
Add a new template literal state to findCompletionBeginning so we can
better handle the autocompletion for them.
Differential Revision: https://phabricator.services.mozilla.com/D4853
--HG--
extra : moz-landing-system : lando
GCLI has been handling the state of our buttons as well as managing shared highlighters.
Since the gcli removal, we no longer share the rulers and measure with any other UI, so a location
for shared state is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D3506
--HG--
extra : moz-landing-system : lando
Summary:
this removes references to GCLI in the inspector front and from the browser menu, leaving
no further uses of gcli eyedropper
Test Plan: mochitests
Reviewers: ochameau
Tags: #secure-revision
Bug #: 1447487
Differential Revision: https://phabricator.services.mozilla.com/D3614
--HG--
extra : rebase_source : a33632edb6127568ec65ca2837ba8c13a3c1ca78
extra : source : d8a1c6a80a59a69ab997f643ce313b022d081e13
Summary:
this removes references to GCLI in the inspector front and from the browser menu, leaving
no further uses of gcli eyedropper
Test Plan: mochitests
Reviewers: ochameau
Tags: #secure-revision
Bug #: 1447487
Differential Revision: https://phabricator.services.mozilla.com/D3614
--HG--
extra : rebase_source : b2e916d0dba1d8f2872720a3558d0e961c0034a9
This patch adds a smarter heuristic for autocompletion results:
if the input first letter is lowercased, then we'll filter
matching properties case insensitively. But if the user starts
with an uppercase, we assume they know the property they want
and thus respect the casing.
For example: `win` will return both `window` and `Window`, but
`Win` will return `Window` only.
Due to this behavior, we change the order of the autocomplete
results so lowercased property are displayed before the uppercased
one.
If we take are example again, it's likely that if a user type `win`,
they want `window`, but the alphabetical order would return `Window`
first which would annoy user.
Now, since we return results that does not match exactly the user
input, we need to modify the frontend.
Usually, we only show the autocompletion popup if there are
at least 2 matching items, since 1 matching item will still
be displayed using the autocompletion text. But now, since the
input might not match, we want to still display the popup if
there is one matching item, but starts differentely than what
the user entered.
For example, the user typed `window.addeve`, which matches
`addEventListener`. The completion text will make it looks like
it will be completed to `window.addeventListener`, which would
be undefined. So showing the popup with the actual matching
property might avoid some confusion for the user.
A test was added to make sure the frontend works as expected.
Some test cases were added in the server test to make sure
the actor returns expected results. Other tests needed some
adjustement because of the insensitive case matches and the
new order of results.
Differential Revision: https://phabricator.services.mozilla.com/D4061
--HG--
extra : moz-landing-system : lando
This patch introduces a screenshot actor, which allows the screenshot functionality to be
shared across tools, and also implements it for the toolbox itself
Differential Revision: https://phabricator.services.mozilla.com/D3341
--HG--
rename : devtools/server/actors/webconsole/screenshot.js => devtools/shared/screenshot/capture.js
rename : devtools/shared/webconsole/screenshot-helper.js => devtools/shared/screenshot/save.js
extra : moz-landing-system : lando
For now, |clip-path: path()| is chrome-only, and not for shape-outside,
so we only implement the parser for clip-path. Besides, I didn't put
path() in BasicShape because path() doesn't use the reference box to
resolve the percentage or keywords (i.e. SVG path only accept floating
point or integer number as the css pixel value). Therefore, I add it into
ShapeSource, instead of BasicShape.
Differential Revision: https://phabricator.services.mozilla.com/D3633
As initially implemented, nsITLSServerSocket by default enabled the use of the
TLS session cache provided by NSS. However, no consumers of nsITLSServerSocket
actually used it. Because it was an option, though, PSM had to jump through some
hoops to a) make it work in the first place and b) not have NSS panic on
shutdown. Furthermore, it meant increased memory usage for every user of Firefox
(and again, nothing actually used the feature, so this was for naught).
In bug 1479918, we discovered that if PSM shut down before Necko, NSS could
attempt to acquire a lock on the session cache that had been deleted, causing a
shutdown hang. We probably should make it less easy to make this mistake in NSS,
but in the meantime bug 1479918 needs uplifting and this workaround is the
safest, most straight-forward way to achieve this.
Differential Revision: https://phabricator.services.mozilla.com/D3919
--HG--
extra : moz-landing-system : lando
The 'x' prefix makes it clearer that these are infallible.
A couple of nsJSID methods are now also infallible.
--HG--
extra : rebase_source : fcce44a00212d6d341afbf3827b31bd4f7355ad5
In wpt, now we support "offset-path: none | path()", so parsing none or
path function should be correct. Animations which animate "from none"
or "to none" will pass because we could serialize "none", even if we
don't support animations on offset-path.
Differential Revision: https://phabricator.services.mozilla.com/D2969
--HG--
rename : testing/web-platform/tests/css/motion/offset-path-string.html => testing/web-platform/tests/css/motion/offset-path-string-001.html
Define OffsetPath & SVGPathData on the servo-side, and StyleMotion &
StyleSVGPath on the gecko-side. We parse the SVG Path string into a
vector of PathCommand. To build the gfx::Path, we will convert it into
gfx::Path later in a different patch.
The basic flow is:
* Parse SVG Path String into SVGPathData (in Rust).
* Use cbindgen to make sure the layout of PathCommand and StylePathCommand,
and then set the Box[PathCommand] into nsTArray<StylePathCommand>.
* Try to convert nsTArray<StylePathCommand> into gfx::Path. (This part
will be implemented in a different patch.)
Finally, we use the gfx::Path to create a motion path transform.
The layout implementation is in the later patch.
Differential Revision: https://phabricator.services.mozilla.com/D2963
These methods are only ever used in tests and no longer need to be exposed.
In test_bug445177.xul I tried to preserve more of the test, but everything
after the call to addBroadcastListenerFor is dependent on that.
MozReview-Commit-ID: C4vAxNir4O8
In the genuine adb binary, when it received 'host:kill' command, it exits the
server process soon [1]. Whereas, in our mock adb.py which is based on
SocketServer.TCPServer in python, when we call
SocketServer.TCPServer.shutdown() in the case of 'kill-server' command, the
server process doesn't exit soon since the shutdown() function just sets a
flag [2] and serve_forever() polls it [3] every |poll_interval| seconds,
|poll_interval| is 0.5 seconds by default. Thus it's possible that new incoming
requests are processed during polling.
This is the real cause of the race condition that the adb server still keeps
alive when 'adb kill-server' finished. So we don't need to the workaround
for the race condition.
[1] 4039051d6d/adb/adb.cpp (1049)
[2] 65b5ef02ec/Lib/socketserver.py (L248)
[3] https://docs.python.org/2/library/socketserver.html#SocketServer.BaseServer.serve_forever
Differential Revision: https://phabricator.services.mozilla.com/D3169
Some test were relying on the existence of the complete function
and were using it in order to do integration test.
We modify those and instead trigger real user interaction for
making those assertions.
Additional test cases are added to the test files they fit in
so we have a broader coverage of user interaction in regard
to autocompletion.
Depends on D2825
Differential Revision: https://phabricator.services.mozilla.com/D2826
--HG--
extra : moz-landing-system : lando
We used to rely on different things to both display
the autocompletion text and accept an autocompletion.
This patches introduces new helper functions in order
to make the code more easy to reason about.
We also rollback our decision to show the popup when
there is only 1 item in the autocompletion list in
order to be more consistent with what Chrome does.
Differential Revision: https://phabricator.services.mozilla.com/D2824
--HG--
extra : moz-landing-system : lando
Entry storage allocation now occurs on the first lookupForAdd()/put()/putNew().
This removes the need for init() and initialized(), and matches how
PLDHashTable/nsTHashtable work. It also removes the need for init() functions
in a lot of types that are built on top of mozilla::Hash{Map,Set}.
Pros:
- No need for init() calls and subsequent checks.
- No memory allocated for empty tables, which are not that uncommon.
Cons:
- An extra branch in lookup() and lookupForAdd(), but not in put()/putNew(),
because the existing checkOverloaded() can handle it.
Specifics:
- Construction now can take a length parameter.
- init() is removed. Explicit length-setting, when necessary, now occurs in the
constructors.
- initialized() is removed.
- capacity() now returns zero when the entry storage is absent.
- lookupForAdd() is no longer `const`, because it can instantiate the storage,
which requires modifications.
- lookupForAdd() can now return an invalid AddPtr in two cases:
- old: hashing failure (due to OOM in the hasher)
- new: OOM while instantiating entry storage
The existing failure handling paths for the old case work for the new case.
- clear(), finish(), and clearAndShrink() are replaced by clear(), compact(),
and reserve(). The old compactIfUnderloaded() is also removed.
- Capacity computation code is now in its own functions, bestCapacity() and
hashShift(). setTableSizeLog2() is removed.
- uint32_t is used throughout for capacities, instead of size_t, for
consistency with other similar values.
- changeTableSize() now takes a capacity instead of a deltaLog2, and it can now
handle !mTable.
Measurements:
- Total source code size is reduced by over 900 lines. Also, lots of existing
lines got shorter (i.e. two checks were reduced to one).
- Executable size barely changed, down by 2 KiB on Linux64. The extra branches
are compensated for by the lack of init() calls.
- Speed changed negligibly. The instruction count for Bench_Cpp_MozHash
increased from 2.84 billion to 2.89 billion but any execution time change was
well below noise.
getManifestFromUnpacked() and isUnpacked() are mostly the same as they are in
binary-manager.js [1] in the adbhelper addon. A big difference is that the
manifest.json copied from the extension is the manifest.json for the
devtools-adb-extension itself, not manifest.json(s) in a subdirectory for
each platforms (e.g. linux/manifest.json).
Due to the verion check in each xpcshell test needs to use a different version
for the test extension, otherwise subsequent tests will use unpacked files in
the first test case, thus the ADB mock won't be used at all.
[1] 0821424b6b/binary-manager.js
In the next patch, we will extract manifest.json in the extension into the
profile directory. And returning a boolean will make getFileForBinary()
simple with the extension version check which will be also introduced in the
next patch.
Expressions like `window . addEventListener` are perfectly valid in JS,
but our autocompletion provider wasn't working well in such case.
We modify the JSPropertyProvider to make sure to handle this kind of
syntax and add test cases to make sure it works as intended.`
Differential Revision: https://phabricator.services.mozilla.com/D2988
--HG--
extra : moz-landing-system : lando
On Windows testNoTargetBinaries fails since we don't remove extracted binaries
in the profile directory when the extension is removed. The original adbhelper
addon doesn't remove them either, so this problem has been underlying
originally. We will fix it in a later bug.
Also on Windows, testStartAndStop and testTrackDevices fail. That's because,
I guess, the adb mock (adb.py) isn't launched properly. I will handle it
once after I take a windows laptop back.
MozReview-Commit-ID: 15wo1S0pX37
--HG--
extra : rebase_source : 3a8c60c174def8f24517e10d916384c5fa5ce45c
On MacOSX connecting to a port which is not started listening gets stuck
(bug 1481963), to avoid the stuck, we make forcibly the function fail.
MozReview-Commit-ID: COVplVPx3vA
--HG--
extra : rebase_source : 2f048e8e8aa7e9b9212c6cfa31f3589b73e0087c
There is a race condition that when we adb.start() finishes, i.e. the ADB server
is launched, the ADB server is not ready to listen from clients yet. To avoid
this race condition in adb.start() function, we do wait until the server gets
ready.
MozReview-Commit-ID: EfSLA9uvhI9
--HG--
extra : rebase_source : 7b5938a3a7687e7072352aa65674631d2b1ee429
It seems that, on chaos mode, we can't receive whole data set at once, i.e.
sending data will be split into some chunks, so the adb mock should check the
sent data length and if there remains still data which has to be sent, we have
to continue sending the rest of the data.
MozReview-Commit-ID: 5jeEH8KpNNW
--HG--
extra : rebase_source : 69bc849a48db649bf4f4786456464d3556a903d7
I am not sure this had caused real issue though.
MozReview-Commit-ID: ISSSJCYcpAm
--HG--
extra : rebase_source : 515934abf244d7cee2605117b3fffc22d88d355b
Changes are:
- s/let/const/g if applicable
- braces for 'if' block
- identation fixes
- Moved a statement in setTimeout callback on the next line.
MozReview-Commit-ID: HyZ9zrbK3iJ
--HG--
extra : rebase_source : 61f217419778cee2e94786f1a9a6c9647dda0f87
Without this change, the test in this patch does fail since when the test
starts, the adb server is still running for the previous test, thus
ADB.start() doesn't start a new adb server, then after that when we check
that the adb server is running by adb-running-checker, it tells us the adb
server is NOT running at that moment.
MozReview-Commit-ID: KRo30WmAsAY
--HG--
extra : rebase_source : 96348d8ee94df375b36b3d68683c292cd770fe86
The new devtools-adb-extension should have adb.json on the top of the extension
directory, and devtools fetches the adb.json and parses it then copies the blobs
into local profile directory.
NOTE: Though we are going to use the same adb.json for all platforms, we will
pack only the corresponding blobs for each platform. E.g. the extension for
Linux64 will have only linux64/adb.
The adb.json should look like this;
{
"Linux": {
"x86": [
"linux/adb"
],
"x86_64": [
"linux64/adb"
]
},
"Darwin": {
"x86_64": [
"mac64/adb"
]
},
"WINNT": {
"x86": [
"win32/adb.exe",
"win32/AdbWinApi.dll",
"win32/AdbWinUsbApi.dll"
],
"x86_64": [
"win32/adb.exe",
"win32/AdbWinApi.dll",
"win32/AdbWinUsbApi.dll"
]
}
}
unpackFile() here is mostly the same as in binary-manager.js in the adbhelper
addon.
MozReview-Commit-ID: 7aprfaaeTAT
--HG--
extra : rebase_source : 64c55066207a21782c0cbd0ca2294baf1ab61d40
Allows non-XUL chrome privilege documents to also use the command
dispatcher. The command dispatcher is created lazily since it will not
always be used.
Update test to reflect removal of the XUL attribute "commandDispatcher"
from content privilege XUL.
MozReview-Commit-ID: HUXMG9kx4ft
parseDeclarations was ignoring html comment tokens, but in fact they
should not be treated any differently from other CSS tokens.
MozReview-Commit-ID: 27Mxt5zbSSJ
--HG--
extra : amend_source : 91e47bbf6951ac9dd4709ac10c49ff51c1781ce8
We only have this so that ::-moz-placeholder keeps serializing as
::-moz-placeholder, but I don't think anybody really cares.
Edge aliases ::-webkit-input-placeholder to ::-ms-input-placeholder at parse
time as well, as can be seen in:
```
let s = document.createElement('style');
s.innerHTML = `input::-webkit-input-placeholder { color: red };`;
document.body.appendChild(s);
document.body.innerHTML = s.sheet.cssRules[0].cssText;
```
And I think this is more consistent with what we do for CSS properties that are
aliases.
Differential Revision: https://phabricator.services.mozilla.com/D2595
MozReview-Commit-ID: 3ImDWamJhxh
The '-moz-menulist-button' value currently behavies identically to the
'menulist-button' value. This is not implemented as an alias because later
patches in this patch series will change the behavior of our pre-existing
'menulist-button' value to more closely match what Chrome does.
The '-moz-menulist-button' value currently behavies identically to the
'menulist-button' value. This is not implemented as an alias because later
patches in this patch series will change the behavior of our pre-existing
'menulist-button' value to more closely match what Chrome does.
--HG--
extra : rebase_source : b66bf6427db5be2eb12f4e0aa36d22a4da46555a
This allows to create NetworkEventActor directly from the parent process
and avoid most of the data being piped from the parent to the content processes.
MozReview-Commit-ID: 8p3A5yl5eVB
--HG--
extra : rebase_source : 49eb0406eff31b8262ac316884a4abd57512f6cf
We have a different order in nsCSSPropertyId for no good reason. The only
invariant there is that longhands come before shorthands, and shorthands before
aliases.
Luckily that's also an invariant that NonCustomPropertyId has, so we can reuse
them.
Differential Revision: https://phabricator.services.mozilla.com/D2463
MozReview-Commit-ID: 1hsQu6hmqiN
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
Some test files were affected by adding a new CoarseType, particularly in XPCShell tests. New rules were added to handle this CoarseType, and in a few cases the IDs of deserialized nodes had to be adjusted. The colors of CoarseTypes have also changed slightly and the resulting tests had to be updated.
--HG--
extra : histedit_source : 99db02f1b6acafb1376f71af3b8fceb9adbbb8e0
Added a new CoarseType that refers to DOM nodes. Updated the trees to represent the CoarseType. Created a new type of count in the heap snapshot that sorts the data by a more descriptive type name. Created the descriptive in JS::ubi::Base.
--HG--
extra : histedit_source : be24efa4d2ccb85e82046d7cf7d2c3a1e13b1fd7
Some test files were affected by adding a new CoarseType, particularly in XPCShell tests. New rules were added to handle this CoarseType, and in a few cases the IDs of deserialized nodes had to be adjusted. The colors of CoarseTypes have also changed slightly and the resulting tests had to be updated.
--HG--
extra : rebase_source : 06d5203023251665adf933215898f83f991dbd1a
It's currently only accessible on XULDocument and XULElement, but that makes porting existing
JS to run in an HTML document inconvenient. We could alternatively change calling JS, but
this can be easily moved and exposed in chrome contexts.
MozReview-Commit-ID: JitYET20NSE
--HG--
extra : rebase_source : 75d823c688cba8d84dc19705e83284be383962f2
This changes the behavior for inspecting rejected Promises such that:
(1) We don't consider them safe getters, treating them as we would a thrown exception
(2) Manually handle the rejection with `catch` when possible, so that we don't create
an error when trying to inspect the promise and leaving it unhandled
MozReview-Commit-ID: HZL4BrjCKkA
--HG--
extra : rebase_source : 45d84b1c8ef5a6fc2a9c060dba44b2f56147740b
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : 9c400bed3c9d29a186fc987c9bd0ffceb37bfd94
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : fbfbcf7608efbfb35c9be4018ff0f4e70b2768d2