- Fixes the references to the correct event handler & InspectorFront after a previous mass refactoring in Bug 1529364.
- Augments a test to ensure the clipboard content is correct executing the context menu action to copy a link.
Differential Revision: https://phabricator.services.mozilla.com/D31765
--HG--
extra : moz-landing-system : lando
Rather than having a separate preference for showing the deprecation message, we should reuse the aboutdebugging new pref
Differential Revision: https://phabricator.services.mozilla.com/D31964
--HG--
extra : moz-landing-system : lando
There was a last minute schedule change for remote debugging release and we will not ride the trains with Firefox 68
The deprecation schedule is therefore shifting by one release. We update the deprecation message in WebIDE here and we should
uplift this change to beta if possible. The patch was written in order to be uplifted, we can go for a simpler version if the
uplift is a no go.
Differential Revision: https://phabricator.services.mozilla.com/D31970
--HG--
extra : moz-landing-system : lando
`GetInternalCommand()` is currently used only by `EditorCommand` and it
treats the additional parameter only when given command is `cmd_align`.
However, the value is complicated since `AlignCommand` allows both `CString`
value and `String` value. Therefore, `EditorCommand::DoCommandParams()` may
fail to solve `cmd_align` to a `Command` value without checking both of them.
Therefore, it must make sense that `GetInternalCommand()` take `nsCommandParams`
as optional argument and check it only when given command matches `cmd_align`.
Then, we don't need to waste unnecessary run-time cost.
Note that this bug has been hidden since `AlignCommand` class does not refer
the `Command` value but refers only `nsCommandParams`. However, the previous
patch makes `EditorCommand::GetParamType()` not allow `Command::DoNothing`.
Therefore, we need this follow-up fix now.
Differential Revision: https://phabricator.services.mozilla.com/D30501
--HG--
extra : moz-landing-system : lando
If `nsIControllerCommand::DoCommandParams()` is called without aParams or
`nsITransferable` pointer, this patch sets nullptr to `aTransferableParam` for
`DoCommandParam()`. This allows each implementation to choose ignore or
return error.
Differential Revision: https://phabricator.services.mozilla.com/D30500
--HG--
extra : moz-landing-system : lando
Only `MultiStateCommandBase::DoCommandParams()` allows `CString` param and
`String` param (the former is preferred). This patch makes
`EditorCommand::DoCommandParams()` aware of this case.
Differential Revision: https://phabricator.services.mozilla.com/D30499
--HG--
extra : moz-landing-system : lando
If `nsIControllerCommand::DoCommandParams()` is called with `nullptr` for its
`aParams`, this patch sets `VoidString()` to `DoCommandParam()` for making
each implementation be able to consider whether the case is an error or
treat it as specific default value.
Differential Revision: https://phabricator.services.mozilla.com/D30498
--HG--
extra : moz-landing-system : lando
If `nsIControllerCommand::DoCommandParams()` is called with `nullptr` for its
`aParams`, this patch sets `VoidCString()` to `DoCommandParam()` for making
each implementation be able to consider whether the case is an error or
treat it as specific default value.
Differential Revision: https://phabricator.services.mozilla.com/D30497
--HG--
extra : moz-landing-system : lando
We should use `Maybe` for `bool` because some command may treat the default
value when the parameter is omitted as `true` or `false. Although, current
implementation does not do that.
Differential Revision: https://phabricator.services.mozilla.com/D30496
--HG--
extra : moz-landing-system : lando
Most `EditorCommand` classes don't require additional params for executing
a command. All of them just calls their `DoCommand()` or returns same result.
So, we can create new virtual method,
`EditorCommand::DoCommandParam(Command aCommand, TextEditor& aTextEditor)`,
which just delegates to `DoCommand()`.
This patch adds some undeclared commands but which are handled by
`EditorCommand` subclasses, and changes `CommandInt` type from `int8_t` to
`uint8_t` since the count of `Command` items becomes over 128.
Differential Revision: https://phabricator.services.mozilla.com/D30495
--HG--
extra : moz-landing-system : lando
Abstracts the streaming details away. Reduces complexity of
`nsDocumentEncoder`.
Differential Revision: https://phabricator.services.mozilla.com/D31767
--HG--
extra : moz-landing-system : lando
Add a special path for the external read barrier API where we inline most of the checks and then always perform the barrier if we call into the engine. This also skips dispatching on trace kind since we know the barrier tracer is always a GCMarker.
This is kind of hacky and I'm not sure how much it gains us (it's difficult to tell in profiles where GC may occur at different times). What do you think?
Differential Revision: https://phabricator.services.mozilla.com/D31803
--HG--
extra : moz-landing-system : lando
Since we now have precise memory accounting for externally allocated memory associated with GC things we should be able to remove use of the existing malloc counter here. This should help with cases where we trigger too many GCs because we think there is more memory associated than there really is.
Differential Revision: https://phabricator.services.mozilla.com/D31806
--HG--
extra : moz-landing-system : lando
We don't need to use JSON since we now support getCommentAt for extra data.
Also add unit tests that are missing.
Differential Revision: https://phabricator.services.mozilla.com/D31208
--HG--
extra : moz-landing-system : lando
`./mach run` doesn't work since `_get_host_platform` returns None. So we should
return `win32` on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D30608
--HG--
extra : moz-landing-system : lando
We don't store post-transform overflow areas for frames within preserve-3d, but we do store pre-transform overflow areas.
Rather than just recomputing the changed overflow for the root, we should recompute overflows for all ancestors up to the 3d root.
Differential Revision: https://phabricator.services.mozilla.com/D31213
--HG--
extra : moz-landing-system : lando
Profiling shows we can spend a lot of time in IntervalSet::Intersection().
Much of this time is spent appending elements to a temporary buffer as we
loop over the two IntervalSets' arrays comparing them. As we append, the
storage of the temporary array is reallocated as the storage must grow to
hold more elements. These reallocations are expensive, as we must copy the
old elements to the new storage.
So before starting the loop, reserve enough capacity to store the upper
bound; the minimum of the two IntervalSets' lengths. This may waste memory,
but will be faster, as expensive reallocations are avoided.
Differential Revision: https://phabricator.services.mozilla.com/D31744
--HG--
extra : moz-landing-system : lando
This assert could be triggered with malformed files, so replace it with an early
return.
Differential Revision: https://phabricator.services.mozilla.com/D30027
--HG--
extra : moz-landing-system : lando
Mp4s using the 'cenc' encryption scheme should contain auxiliary information
containing the initialization vector to be used to decode that sample. However,
it's possible for malformed mp4s to contain other relevant crypto information,
but to omit this aux info. This adds such a file to our crashtests.
Differential Revision: https://phabricator.services.mozilla.com/D30025
--HG--
extra : moz-landing-system : lando
The zipfile.is_zipfile() function is overly lenient, in that non-zip
files that contain the four bytes "PK\005\006" near the end of the file
are reported as zip files even if the zip structure is not valid.
Occasionally, our target.tar.bz2 files randomly contain those 4 bytes at
the expected location, which causes the mar repackaging code to try to
process the package as a zip file instead of a tar file.
The tarfile.is_tarfile() logic looks a little more robust in that it
actually tries to open the file, so if we try tar first before falling
back to zip we should be a little more resilient.
Differential Revision: https://phabricator.services.mozilla.com/D31908
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
