This patch basically reverts the functional part of changeset 52bd865d757c.
I'd optimistically hoped we could skip this early-freeze in order to compute &
report a bit more "potential flexing" information via devtools. Bbut it turns
out that breaks assertions & produces bogus information for flex items whose
base size vs. min/max-clamped "hypothetical" sizes are very
different. (Specifically: it produces nonsense for flex items whose base sizes,
if unclamped, would reverse the directionality of flexing.)
Differential Revision: https://phabricator.services.mozilla.com/D9304
--HG--
extra : moz-landing-system : lando
The gains passed to GainStereoToStereo() are applied on only one of the input channels.
Depends on D9213
Differential Revision: https://phabricator.services.mozilla.com/D9214
--HG--
extra : moz-landing-system : lando
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
Differential Revision: https://phabricator.services.mozilla.com/D6944
--HG--
rename : docshell/base/nsDocShellLoadInfo.cpp => docshell/base/nsDocShellLoadState.cpp
rename : docshell/base/nsDocShellLoadInfo.h => docshell/base/nsDocShellLoadState.h
extra : moz-landing-system : lando
This patch also updates the expectations in the mochitest test_flex_items.html.
Before this commit, the test (incorrectly) expected the mainBaseSize API to
return some items' *final sizes*, because that's what our implementation did
return, up until now. As of this patch, that API will now return the item's
actual flex base size, which means the text expectations need to change.
I'm also adding a new flex item to the test, to exercise a formerly-untested
scenario. And to accommodate this new item, I'm also doubling the width of
the flex container to be sure there's plenty of space.
Differential Revision: https://phabricator.services.mozilla.com/D8476
--HG--
extra : moz-landing-system : lando
The majority of the XUL broadcaster logic is moved out of XULDocument and
into a separate class (XULBroadcastManager). The hookup points for when
listeners need to be created and listeners need to be notified is now
handled by the XULElement itself and nsDocument. To avoid any overhead,
the XULBroadcastManager is only ever created when a document uses a
listener.
The new approach does have the disadvantage that broadcasting can now only
work with XULElements, but going forward we'd like to discontinue this
feature and rely on MutationObservers to implement similar things.
One test had to be modified to use XUL elements instead of HTML elements
because of the reason noted above.
Differential Revision: https://phabricator.services.mozilla.com/D8888
--HG--
extra : moz-landing-system : lando
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.
Instead of creating a timer and then setting the timer's target, we can
determine the timer's target and pass it in directly when the timer is
created. This reordering of steps is slightly more efficient, since
SetTarget() is both a virtual call and requires locking, both of which
can be skipped if we know the target at timer creation time.
Disable dom.xhr.standard_content_type_normalization for now due to webcompat issues
Differential Revision: https://phabricator.services.mozilla.com/D8789
--HG--
extra : moz-landing-system : lando
This patch changes the way we set and handle the preferred alternate data type.
It is no longer just one choice, but a set of preferences, each conditional
on the contentType of the resource.
For example:
var cc = chan.QueryInterface(Ci.nsICacheInfoChannel);
cc.preferAlternativeDataType("js-bytecode", "text/javascript");
cc.preferAlternativeDataType("ammended-text", "text/plain");
cc.preferAlternativeDataType("something-else", "");
When loaded from the cache, the available alt-data type will be checked against
"js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes.
Note that the alt-data type could be "something-else" even if the contentType is "text/javascript".
The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>.
Differential Revision: https://phabricator.services.mozilla.com/D8071
--HG--
extra : rebase_source : eb4961f05a52e557e7d2d986d59e0a2cf18a3447
extra : source : dd1c31ea78c2b15d14750d137037a54d50719997
PresShell::PageMove() climbs up to parent document when there is no scrollable
parent in current document. However, if aExtend is true, it should expand
Selection in the document itself. Therefore, it needs different rules to
look for container of expanding Selection from scrollable element to scroll.
Additionally, old rules (i.e., before the fix of bug 1369072 which caused
this regression) were also buggy. It used parent scrollable element or
root scrollable element simply. Therefore, if found scrollable element is
ancestor of selection limiter, it didn't work as expected.
This patch creates nsFrameSelection::GetFrameToPageSelect() to retrieve
per-page selection container element with the following rules:
- look for a scrollable element in selection limiter.
- if there is no scrollable element, use selection limiter.
- if there is no selection limiter, use the root frame.
So, nsFrameSelection::CommonPageMove() should take nsIFrame rather than
nsIScrollableFrame since container of per-page selection may be used in
non-scrollable contenteditable element. If it's called with non-scrollable
frame, it needs to compute the expanding range with the frame size.
Differential Revision: https://phabricator.services.mozilla.com/D8954
--HG--
extra : moz-landing-system : lando
Primary changes:
- Rewrap some lines that are too long.
- Adjust some failure-messages with s/has/should have/ etc.
- Replace 'nearlyEqual' function with the standard mochitest
'isfuzzy()' API (which is like 'is()' with an extra epsilon arg)
- Remove dependence on hardcoded element IDs, and simply walk over the
flex container's children in order instead (still noting each child node
and making sure it matches the node in the flex API).
Differential Revision: https://phabricator.services.mozilla.com/D8933
--HG--
extra : moz-landing-system : lando
This patch changes the way we set and handle the preferred alternate data type.
It is no longer just one choice, but a set of preferences, each conditional
on the contentType of the resource.
For example:
var cc = chan.QueryInterface(Ci.nsICacheInfoChannel);
cc.preferAlternativeDataType("js-bytecode", "text/javascript");
cc.preferAlternativeDataType("ammended-text", "text/plain");
cc.preferAlternativeDataType("something-else", "");
When loaded from the cache, the available alt-data type will be checked against
"js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes.
Note that the alt-data type could be "something-else" even if the contentType is "text/javascript".
The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>.
Differential Revision: https://phabricator.services.mozilla.com/D8071
--HG--
extra : moz-landing-system : lando
