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
The Webrender Pref Experiment is reporting its pref via telemetry and that
is reporting a different value than what the Normandy experiments telemetry
indicates should be being seen.
So add reporting for two dummy prefs, one with a default value, and one
without. We intend to push out Normandy rules to report these prefs to
double-check that Normandy is working as expected.
Differential Revision: https://phabricator.services.mozilla.com/D8926
--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
Now that all Windows builds have static analysis enabled, the
clang_debug mozharness config does not have any relevant difference for
those jobs, so just use the debug mozharness config instead.
Depends on D8810
Differential Revision: https://phabricator.services.mozilla.com/D8811
--HG--
extra : moz-landing-system : lando
This was separate because at some point in the past we were calling
-[ChildView drawRect:inContext:] from a separate draw-in-titlebar pass. That separate
pass was removed in bug 676241.
Depends on D7929
Differential Revision: https://phabricator.services.mozilla.com/D7931
--HG--
extra : moz-landing-system : lando
I don't think anybody has made use of this code in years.
Depends on D7927
Differential Revision: https://phabricator.services.mozilla.com/D7928
--HG--
extra : moz-landing-system : lando
This override was intended to ignore unnecessary nsChildView::Invalidate calls
when using main thread OpenGL. With OMTC, Gecko no longer calls Invalidate in
those cases, it just composites on the compositor thread, and the widget's main
thread code doesn't really hear about it. So this workaround is no longer necessary.
Depends on D7925
Differential Revision: https://phabricator.services.mozilla.com/D7927
--HG--
extra : moz-landing-system : lando
The main thread layer manager is always NONE, BASIC or CLIENT. It is never OPENGL anymore.
Main-thread OpenGL rendering was removed in bug 924403.
Depends on D7924
Differential Revision: https://phabricator.services.mozilla.com/D7925
--HG--
extra : moz-landing-system : lando
This was an experiment before we had e10s. It's no longer needed.
Depends on D7922
Differential Revision: https://phabricator.services.mozilla.com/D7924
--HG--
extra : moz-landing-system : lando
Many years ago, Gecko would sometimes call nsChildView::Invalidate during drawRect:.
This is no longer the case: Widget invalidations now only happen outside of drawRect,
usually from a refresh tick or from viewWillDraw.
Differential Revision: https://phabricator.services.mozilla.com/D7922
--HG--
extra : moz-landing-system : lando
If nsSecureBrowserUIImpl::OnLocationChange receives a
LOCATION_CHANGE_SAME_DOCUMENT notification, it doesn't need to (and in fact
shouldn't) update its security state or notify downstream listeners.
Differential Revision: https://phabricator.services.mozilla.com/D8900
--HG--
extra : moz-landing-system : lando
Now that the XPCOM component loader infrastructure has stopped
pretending to support other file extensions, this intermediate
interface is no longer needed.
Depends on D8171
Differential Revision: https://phabricator.services.mozilla.com/D8172
--HG--
extra : moz-landing-system : lando
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
--HG--
extra : moz-landing-system : lando
This allows some code to be deleted, including a KnownModule ctor.
Depends on D8168
Differential Revision: https://phabricator.services.mozilla.com/D8169
--HG--
extra : moz-landing-system : lando
This interface is only used for a few testing functions. Just move
them to Cu.
Differential Revision: https://phabricator.services.mozilla.com/D8168
--HG--
extra : moz-landing-system : lando
And make will-change: position properly create an abspos cb while at it, since the check was missing the `mWillChangeBitfield & ABSPOS_CB` bit.
Differential Revision: https://phabricator.services.mozilla.com/D8743
--HG--
extra : moz-landing-system : lando
When we're creating a scrollframe with let's say, display: flex or grid, the
containing block is the grid container itself, but the transformed frame is the
scroll frame.
This is the only caller that (incorrectly) passes the same frame to
PushAbsoluteContainingBlock.
Our painting code deals with it, mostly, because it starts from the placeholder
to paint fixed items, and it hits the scrollframe, but it gets confused
sometimes causing the issue described here.
I'll find a way to add a crashtest for this, and maybe a reftest, though this
works in non-WR.
We should probably add a few more assertions to the frame constructor...
Differential Revision: https://phabricator.services.mozilla.com/D8724
--HG--
extra : moz-landing-system : lando
In trying to use fetch with alt-data, we sometimes want the benefit of using alt-data but the JS consumer actually needs to use the original HTTP response from the server.
To get around this problem, we introduce a new API - nsICacheInfoChannel.getOriginalInputStream(nsIInputStreamReceiver) that asyncly receives the input stream containing the HTTP response in the cache entry.
Depends on D8071
Differential Revision: https://phabricator.services.mozilla.com/D8072
--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
The autoplay shield-study which will run on Release 63 needs one of these data and we also want to analysis other data in order to improve the user experience of blocking-autoplay.
Differential Revision: https://phabricator.services.mozilla.com/D9014
--HG--
extra : moz-landing-system : lando
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
The desired outcome of this change is that we'll set
-Wl,--version-script based on linker kind and not on the output of
$LINKER -v.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system ld is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system ld doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system ld.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
MinGW suffers somewhat from the opposite problem: the linker "is GNU
ld" (compatible), but the linker checks don't happen at all. We hard-code
for MinGW based on the C compiler instead.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
Masayuki Nakano
Jared Wein
Dorel Luca
Thomas Wisniewski
Chris Pearce
Ehsan Akhgari
Daniel Holbert
Jeff Gilbert
Tom Prince
Mike Hommey
Jim Blandy
Eitan Isaacson
Markus Stange
Dana Keeler
Sebastian Hengst
Andrew Halberstadt
Andrew McCreight
Emilio Cobos Álvarez
Valentin Gosu
alwu
Edouard Oger
Micah Tigley
Nick Alexander