The previous |if (data)| check is not quite the same as !data.IsEmpty(), because
the previous code just checked if the do_QueryInterface failed, but not if the resulting
string is empty.
Differential Revision: https://phabricator.services.mozilla.com/D10438
--HG--
extra : moz-landing-system : lando
Keep our old 'progressbar' as an alias for now, but unship
'progresschunk' by restricting it to UA/chrome sheets only.
Unship 'progresschunk-vertical' by removing it since it's
not used internally for anything.
This also includes implementation of nsNativeThemeCocoa::GetWidgetAutoColor
which should have been done in bug 1464722 actually.
Differential Revision: https://phabricator.services.mozilla.com/D8629
--HG--
extra : moz-landing-system : lando
Our implementation of this method was removed in bug 1070710. I forgot to remove the declaration in that bug.
Differential Revision: https://phabricator.services.mozilla.com/D7947
--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
The assertion was reasonable check before fixing bug 1446401. However,
this is currently valid situation in UI Events spec.
Differential Revision: https://phabricator.services.mozilla.com/D7578
--HG--
extra : moz-landing-system : lando
If we do not pass the high quality scaling flag than the resulting surface will be marked as cannot substitute, which is not accurate, so we don't want.
The only place that actually tries to be smart about the size is nsImageFrame::MaybeDecodeForPredictedSize. All other cases just ask for the intrinsic size.
The two most likely cases are that there are no decoded copies of the image, or there is one decoded (or in progress) copy of the image.
In the first case we will request decode at the instrinsic size, and then if we draw at a different size that draw will request the proper size. This doesn't change with this patch.
In the second case there is a decoded copy already available, this is likely from a draw call on the image, and that is the surface size that we want. So we save a decode. If we are actually drawing the image at two different sizes the second size will be slightly delayed, but we have the wrongly sized copy of the image that we can draw until then. This seems like a good tradeoff to avoid always decoding an instrinic size copy of images.
On Mojave (or later versions) defaultCenter doesn't get the
accessibilityDisplayShouldReduceMotion changes, we need to use
sharedWorkspace.notificationCenter instead.
Note that the reason why we use defaultCenter originally is that using
sharedWorkspace.notificationCenter to post a notification (for mochitest)
crashed on MacOSX 10.10 (on a try).
Differential Revision: https://phabricator.services.mozilla.com/D6201
--HG--
extra : moz-landing-system : lando
If a key inputs multiple characters, we dispatch same number eKeyPress
events to input each character. However,
TISInputSourceWrapper::WillDispatchKeyboardEvent() always sets
charCode of all eKeyPress events to first character of inserting.
Instead, it should set charCode value to nth character of the
inserting string.
Differential Revision: https://phabricator.services.mozilla.com/D5884
--HG--
extra : moz-landing-system : lando
Mats Palmgren
Michael Froman
Bogdan Tara
Tom Schuster
arthur.iakab
Markus Stange
Jonathan Watt
Daosheng Mu
Gabriele Svelto
Lee Salzman
Xidorn Quan
Margareta Eliza Balazs
Neil Deakin
Narcis Beleuzu
Masayuki Nakano
Andrew McCreight
Timothy Nikkel
Stephen A Pohl
Noemi Erli
Nicholas Nethercote
Ehsan Akhgari
Miko Mynttinen
Hiroyuki Ikezoe
Jeff Muizelaar
Andreea Pavel
shindli