In order not to miss the second cue, we extend the duration of both the second and third cue to 1 second. And adjust the third cue's start time to keep them non-overlapping.
Differential Revision: https://phabricator.services.mozilla.com/D38529
--HG--
extra : moz-landing-system : lando
Many of these features are non-functional these days, but I'll keep them
hooked up in case we decide to fix them.
Differential Revision: https://phabricator.services.mozilla.com/D38413
--HG--
extra : moz-landing-system : lando
The call needs to be part of the bytecode op for the JIT, but the interpreter can emit
a single call at the end. Results in more compact code and we can now assert unique
callVMs in recordCallRetAddr.
Depends on D38477
Differential Revision: https://phabricator.services.mozilla.com/D38633
--HG--
extra : moz-landing-system : lando
At this point most of the DebugModeOSR complexity came from dealing with the
On -> Off case because debugger callVMs are not present in the recompiled script.
We also had to worry about loading unsynced stack values in R0/R1 in the
DebugTrap case (because it resumes at the start of a bytecode op).
We can now change these cases to resume after the corresponding Interpreter
callVMs instead. This lets us remove BaselineDebugModeOSRInfo and the
continuation fixer trampoline. We also no longer have to worry about unsynced
R0/R1 stack values for DebugTrap because the interpreter always has a synced
stack at the beginning of a bytecode op.
This removes about 360 lines of complicated code. It also fixes a memory leak the
fuzzers found a few days ago (bug 1566189).
Differential Revision: https://phabricator.services.mozilla.com/D38477
--HG--
extra : moz-landing-system : lando
I added `-moz-user-select: none;` to the `.badge` class in devtools/client/accessibility/accessibility.css .
Differential Revision: https://phabricator.services.mozilla.com/D37730
--HG--
extra : moz-landing-system : lando
If the script already has a BaselineScript or the Interpreter/JIT thresholds are the same,
we will immediately switch to Baseline JIT code at the same LOOPENTRY op. This should be
unlikely for most loops and the extra overhead for this case is negligible.
Differential Revision: https://phabricator.services.mozilla.com/D38280
--HG--
extra : moz-landing-system : lando
This unblocks clean up of Ion bailouts and Baseline because we can now assume
the interpreter is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D38279
--HG--
extra : moz-landing-system : lando
This is more symmetrical with baselineInterpreterWarmUpThreshold and the
baselineInterpreter/baselineJit options.
Differential Revision: https://phabricator.services.mozilla.com/D38278
--HG--
extra : moz-landing-system : lando
They're wrong. When a property that affects the parent frame changes, we get a
hint for both frames. This fixes this bug.
Depends on D38598
Differential Revision: https://phabricator.services.mozilla.com/D38599
--HG--
extra : moz-landing-system : lando
This is IMO the right RestyleManager change for what bug 1527210 tried to fix.
We need to apply the animation hints to the primary frame, not the style frame.
The other non-RestyleManager bits of that bug still apply and look fine to me.
Differential Revision: https://phabricator.services.mozilla.com/D38598
--HG--
extra : moz-landing-system : lando
Seems we can leave this node alive for too long if the user scrolls between
domcontentloaded (where GoToAnchor is called) and onload (where ScrollToAnchor()
is called).
Though it seems we can leave it for too long if we don't end up calling
ScrollToAnchor(), the documentation of the method claims that it's cleared
unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D38398
--HG--
extra : moz-landing-system : lando
This is a potential fix that I thought it was worth doing rather than
implementing Blink's platform-dependent silliness. This ensures that the display
frame always has enough space to display itself.
Note that it may still get clipped, if there's no room for both the display
frame and the button.
Differential Revision: https://phabricator.services.mozilla.com/D37922
--HG--
extra : moz-landing-system : lando
This is a similar concept as `nullptr` is to a pointer.
`BlocksRingBuffer` now skips the first byte in the buffer, so that no entries
start at 0 (the internal default `BlockIndex` value).
All `BlocksRingBuffer` public APIs handle this default value, and do nothing
and/or return Nothing (as if it pointed at an already-deleted entry).
Added tests for this, and for all BlockIndex operations.
Differential Revision: https://phabricator.services.mozilla.com/D38667
--HG--
extra : moz-landing-system : lando
This just changes the `TITLE_TAGS_SEPARATOR` to the non-printable character `\x1F`, the unit separator, which seems appropriate.
At first I thought we could use the result label to store tags since we're not using the label at all right now. Hacky, but better than storing them in the title. But (1) `nsAutoCompleteSimpleResult::GetLabelAt` falls back to the value if the label is empty, and (2) `nsAutoCompleteController::GetLabelAt` actually returns the same thing as `GetValueAt`, i.e., the value, not the label. It's doable, but we'd need set the label to some special value for every result that doesn't have tags so that the label doesn't fall back to the value so we can tell which results don't have tags, and we'd need to make sure to always directly ask results for labels instead of going through the controller. head_autocomplete.js goes through the controller, and I didn't check what else does too.
So then I thought we could store tags in the style with a special substring like "tags=tag1,tag2,tag3". Again it's doable, but:
The simplest fix is to just change the separator to an unprintable character. That should work, right? We can do better whenever we finally rewrite/refactor UnifiedComplete for quantumbar.
Differential Revision: https://phabricator.services.mozilla.com/D38790
--HG--
extra : moz-landing-system : lando
Rules and their declarations are a single object as far as the CC is concerned. They have a single nsCycleCollectionISupports and they are represented by a single node in the CC graph. That single object has two nsWrapperCache instances in it that point to different JS objects, and we need to make sure that the ordering of the unlink operations for those nsWrapperCache instances is handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D38326
--HG--
extra : moz-landing-system : lando
This gets the wrench android builds working again after
07168db23c565e4506690612a7be50738844ddb2.
Differential Revision: https://phabricator.services.mozilla.com/D38882
--HG--
extra : moz-landing-system : lando
Add the network.trr.mode pref, which reflects whether DNS over HTTPS is enabled or not, to the telemetry environment.
Differential Revision: https://phabricator.services.mozilla.com/D38743
--HG--
extra : moz-landing-system : lando
Eugen Sawin
Eugen Sawin
alwu
Cameron McCormack
Bogdan Tara
Jan de Mooij
Edwin Gao
Aki Sasaki
Krishnal Ciccolella
Agi Sferro
Carolina
Emilio Cobos Álvarez
Hiroyuki Ikezoe
Eric Rahm
Gerald Squelart
Shane Caraveo
Boris Zbarsky
harry
Bobby Holley
Kirk Steuber
Drew Willcoxon
Kershaw Chang
Steve Fink
Benjamin
Jeff Muizelaar
Sean Feng
Tim D. Smith