I verified that we can still copy from Firefox to an older version of Firefox without this patch.
LibreOffice also still works. Talking to some GTK people on IRC they are also happy about UTF-8 instead of wrongly declared UCS2.
Differential Revision: https://phabricator.services.mozilla.com/D8467
--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 : rebase_source : 43d92c631b964c52b551a700b0954276e91695d6
extra : source : 7f9d03c29a6ffd82c1b5e17c14e27a2ae9d64434
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
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
Brian Hackett
Florian Quèze
Bob Clary
Julian Descottes
Margareta Eliza Balazs
Tom Schuster
Dão Gottwald
yulia
Valentin Gosu
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