Creating iframe/img/sript in the same window for each sub-test sometimes
causes the iframe/img/script fail to load.
This issue fix the intermittent failure by creating a new window for
each sub-test.
Differential Revision: https://phabricator.services.mozilla.com/D88278
It's disabled in the Nightly channel and early beta half a year ago, but there
are no regression reports and Chrome has already disabled it since 2014.
So, let's disable this feature on the Release channel (and late Beta) too
for better security and making simpler implementation in the future.
Differential Revision: https://phabricator.services.mozilla.com/D87992
To prevent performance degration and extra memory usage in Firefox
for newly spawned content processes, only load external modules if
required in both the parent and child actor.
Differential Revision: https://phabricator.services.mozilla.com/D88138
Normally I believe it's good to keep functionally-distinct code in separate functions when appropriate.
However in this case, this `ChunkedJSONWriteFunc::GetTotalLength()` function was only used internally, so it's easy to hide it. It is not very big, so it's less important to keep it separate. And its code (going through all chunks to collect sizes) is similar to the code that follows (going through all chunks to collect their content), so it makes some sense to have these similar things in the same place; if one day this chunking change, both loops would probably have to be modified at the same time.
More importantly to justify this change: It was including the final null terminator, which was a bit inconsistent with the usual `Length()` functions in string containers.
Now that code is only used where absolutely necessary (before allocating an output buffer), so it rightly accounts for the null terminator that is added at the end of the contents.
And in upcoming bug 1612799, `ChunkedJSONWriteFunc` will have a new "retired" state (e.g., after an internal memory allocation failed) in which case a public `GetTotalLength()` function could give misleading results -- should it be 0 (nothing to output), 1 (only the null terminator), 5 ("null"), or the length of some error message? So I think it's better not to expose such an ambiguous function.
It could of course be re-introduced if new needs arise in the future.
Differential Revision: https://phabricator.services.mozilla.com/D87833
In most calls to `SpliceableJSONWriter::Splice(const char*)`:
- The data comes from a `ChunkedJSONWriteFunc` and is copied to a new buffer, which is then copied again through `Write()`. Instead we can copy the data directly from the `ChunkedJSONWriteFunc`; and this is a nice complement to `TakeAndSplice()` below.
- Or the length is already known, so we can pass it to a new `Splice(const char*, size_t)`, which forwards it to `Write(const char*, size_t)`, saving one `strlen` call.
Differential Revision: https://phabricator.services.mozilla.com/D87703
`SpliceableChunkedJSONWriter::ChunkedWriteFunc` returns a `ChunkedJSONWriteFunc*`, which is never null and is either used to:
1. Copy data.
2. Or take ownership of the chunks.
In the first case, `ChunkedWriteFunc()` now returns a `const ChunkedJSONWriteFunc&` (notice "const &"), so only const members may be used to copy the data.
In the second case, a new function `TakeChunkedWriteFunc()` returns `ChunkedJSONWriteFunc&&` (notice "&&"), so it's clear that its chunks can be taken away. Some `DEBUG` assertions help ensure that it's not used anymore after that.
`TakeAndSplice()` now takes a `ChunkedJSONWriteFunc&&`.
All callers have been updated to the more appropriate functions.
Differential Revision: https://phabricator.services.mozilla.com/D87702
The editor modules does QI too many times when it sets or removes some style
with `execCommand` or XPCOM API. Therefore, there should be an API to
retrieve `nsStyledElement` pointer from `nsINode*`.
Differential Revision: https://phabricator.services.mozilla.com/D87990
Although it starts to return error if it causes destroying the editor, but
it should not occur because it modifies new and orphan node and it shouldn't
kick any mutation event listeners. Therefore, this patch makes the callers
handle error as-is rather than ignoring errors except
`NS_ERROR_EDITOR_DESTROYED`.
Differential Revision: https://phabricator.services.mozilla.com/D87989
It should take `nsStyledElement&` instead of `const Element&`. Then, it won't
fail and will just return the result of `nsStyleElement::Style()`. Therefore,
we can get rid of it.
Note that this patch makes all its callers keep using strong pointer because
I'm not sure whether the layout APIs which are called with them are safe or
not.
Differential Revision: https://phabricator.services.mozilla.com/D87982
Previously, the browser dialogTemplate contained role="dialog" and the Print modal body had no role.
This caused screen readers to extraneously report "dialog, Print grouping".
Dialogs presented with commonDialog.xhtml (e.g. using Services.prompt.alertBC) did have the dialog role on the body, so screen readers would report "dialog, {dialogTitle} dialog".
To fix this, remove role="dialog" from dialogTemplate.
Instead, SubDialog now sets role="dialog" on the dialog document when it loads.
Now, screen readers report just "Print dialog" and "{dialogTitle} dialog", respectively.
Differential Revision: https://phabricator.services.mozilla.com/D87977
Previously, IsFocusable returned true on elements in print preview documents, but the element wouldn't accept focus.
This meant that when you tried to tab, focus would get stuck on the document.
Now, IsFocusable returns false.
Thus, tab doesn't try to stop on these elements and can move out of the document.
Differential Revision: https://phabricator.services.mozilla.com/D88000
This change introduces a `getChildren` method to the IOUtils interface, which
returns an array of absolute paths pointing to the immediate children of a
directory.
This method should provide equivalent (though not the same) functionality to
iterating directory entries using a new `OS.File.DirectoryIterator`.
Differential Revision: https://phabricator.services.mozilla.com/D87875
IOUtils is meant to act as a drop-in replacement for OS.File. Previously,
IOUtils would block shutdown at the XPCOMWillShutDown phase to allow pending
I/O tasks to finish, however, OS.File blocks for the same reason during the
ProfileBeforeChange phase.
To make IOUtils directly compatible with OS.File, we now match this behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D87511
This change introduces two new methods to the IOUtils interface:
1. `readUTF8` will read an entire file as an UTF-8 encoded text
2. `writeAtomicUTF8` will encode a provided DOMString to UTF-8 and write it
to file
Differential Revision: https://phabricator.services.mozilla.com/D87020
This changes fixes some failing extension tests on unixes. These failures were
caused by a mismatch in time precision used by nsIFile and OS.File's
implementations.
The fixes are as follows:
1. Use IOUtils (the C++ port of OS.File) methods where possible.
2. Update the OS.File.setDates implementation to use a higher time precision
when setDates is called. Eventually, all calls to OS.File.setDates will
be replaced by IOUtils.touch.
Differential Revision: https://phabricator.services.mozilla.com/D86831
This change updates the unix implementation of nsLocalFile
Set/GetLastModifiedTime methods to improve the precision of file modification
times from a 1 second resolution to a 1 millisecond resolution.
Differential Revision: https://phabricator.services.mozilla.com/D86238
This patch introduces a touch method to the IOUtils method, which allows
callers to update the modification time for a file on disk.
Differential Revision: https://phabricator.services.mozilla.com/D86832
Dimi Lee
Masayuki Nakano
Tom Tung
Emilio Cobos Álvarez
Sebastian Hengst
Jonathan Kew
Mihai Alexandru Michis
Alexandre Poirot
Henrik Skupin
Gerald Squelart
Sylvestre Ledru
Simon Giesecke
James Teh
Razvan Maries
Mike Hommey
Nicholas Nethercote
Keefer Rourke