We're seeing a lot of cases where our "check for zombie child processes"
check is finding live processes, but the minidumps that we get from such
processes are nonsense, and don't even feature Firefox symbols.
The working theory at this point, courtesy of bobowen, is that child
processes that we launch are getting closed during the test runs,
completely normally, and then we are finding other (non-Firefox) live
processes with the PIDs that were used for Firefox child processes at
the end of the test run. This scenario is plausible due to Windows's
aggressive reuse of PIDs. We don't see the same behavior on our Unix
test machines because Linux (and OS X, apparently) are not nearly as
aggressive in reusing PIDs.
Since we should be ensuring that any live processes are actually Firefox
processes anyway, let's add the appropriate check. If the check works
to reduce the incidence of zombiecheck failures, that's great! If not,
we've at least made our test runner more robust and can investigate
other possibilities for these intermittent failures.
Windows documentation indicates that it's invalid to WaitForSingleObject
on a process handle unless you request the SYNCHRONIZE access right.
And indeed, we see errors in the logs like:
09:58:28 WARNING - mozcrash kill_pid(): wait failed (-1) terminating pid 6340: error 5
That "error 5" is an ERROR_ACCESS_DENIED code. Such errors should go
away with requesting the proper access rights. Credit to dmajor for
noticing the discrepancy.
Summary:
For every `Enter` or `Shift+Enter` ACTION_DOWN event a new next/previous search
will be made.
Keeping the buttons pressed will cycle through all the search results endlessly.
Depends on D17133
Reviewers: JanH
Reviewed By: JanH
Bug #: 1498911
Differential Revision: https://phabricator.services.mozilla.com/D18203
--HG--
extra : histedit_source : 626b863aa35e63e113be81deecadd8193f1e1c01
If all parts of a table are non-standard display types, like all elements being display:block;, we weren't properly determining table cell indices because we weren't always taking into account thead, tbody, or tfoot elements. This patch:
* Exposes non-standard tbody, tfoot and thead elements as groupings, similar to ARIA rowgroup.
* Adjusts the one instance in nsAccessibilityService::CreateAccessible that didn't account for the table not being the direct parent of the row node, but the grandparent instead.
Differential Revision: https://phabricator.services.mozilla.com/D18333
--HG--
extra : moz-landing-system : lando
Current window state in the sessionstore system includes `sizeMode` which can be "normal", "minimized", "maximized". However, the OS also remembers whether the window was "normal" or "maximized" before minimization to restore it appropriately. With this fix, sessionstore does likewise.
Differential Revision: https://phabricator.services.mozilla.com/D13234
--HG--
extra : moz-landing-system : lando
There's some new limited const fn support in stable, and this is the recommended
way to initialize atomics now.
If this for some reason doesn't compile in all platforms / versions we support
I'll just sprinkle some #[allow(deprecated)] instead.
Also, cargo changes the output of Cargo.lock, see
https://github.com/rust-lang/cargo/issues/6180. So also update those comments.
Differential Revision: https://phabricator.services.mozilla.com/D18495
--HG--
extra : moz-landing-system : lando
Doing it during layout instead. This also has the nice side-effect of
no longer needing to do a full restyle when counter-style rules are inserted.
Differential Revision: https://phabricator.services.mozilla.com/D18343
It may not be safe to handle events even when
PresShell::EventHandler::HandleEvent(). In such case, we need to discard
received events with notifying somebody. This patch move this rare case
jobs into the new method, MaybeDiscardEvent(). Then, the caller, HandleEvnet(),
becomes easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D16960
--HG--
extra : moz-landing-system : lando
This is just a VM call in the interpreter. We could optimize this with an IC or
inline path if it ever becomes a problem.
Differential Revision: https://phabricator.services.mozilla.com/D17935
--HG--
extra : moz-landing-system : lando
This adds js::SingletonObjectLiteralOperation and calls it from both the
interpreter and Baseline. The Baseline compiler still has a fast path for the
cloning-not-necessary case.
Differential Revision: https://phabricator.services.mozilla.com/D17934
--HG--
extra : moz-landing-system : lando
Let's move the redirection of coming event in
PresShell::EventHandler::HandleEvent() into a method. This makes the caller
easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D16959
--HG--
extra : moz-landing-system : lando
This makes our behavior a bit closer to Blink / WebKit.
This patch fixes multiple issues:
First, fixes the caret movement getting stuck on a <select> element inside an
editor. This is because of the IsRootOfAnonymousSubtree() check that I'm
removing. Instead of that, consider NAC unselectable in UsedUserSelect, just
like generated content. This makes us jump across it correctly, and doesn't
regress the test-case that was added in bug 989012.
Second, it allows to select nodes with user-select: none as long as you're on an
editor. This matches WebKit and Blink. It's something you could do earlier
regardless with user-select: all on the parent, which is why the reporter's
test-case worked before my patch. I think being able to jump across these and
delete them on an editor is the right thing to do.
It adds tests for all this plus the same thing working for non-editable contents
(there was no pre-existing test for that).
Differential Revision: https://phabricator.services.mozilla.com/D18494
--HG--
extra : moz-landing-system : lando
Convert resetProfile.dtd to resetProfile.ftl. Modify dependencies for resetProfile.xul, safeMode.xul, aboutSupport.xhtml.
Differential Revision: https://phabricator.services.mozilla.com/D17416
--HG--
extra : moz-landing-system : lando
The fix in bug 1312243 introduced a maximum of three consecutive cancelations (controlled by a pref) that a user could perform until Firefox would prevent the page from showing more dialogs.
This, in my opinion, is a great idea. The implementation, however, has a major fallacy: It checks the inner window id in the well-meaning attempt to find user navigation or reloads and clears its internal counter when that window id changes. Unfortunately this also clears the counter on non-user-initiated navigations and reloads. I believe that the true intention of the patch was to cancel the auth dialog after 3 attempts, except if:
- The user reloads the page on their own terms
- The user navigates to a different site on their own
Which is what I plan to implement, using the same pattern we applied to implement temporarily blocked site permissions:
- Temporarily store basic auth counter state on the browser object, as a map from baseDomain (eTLD+1) to number of cancellations
- Reset this state only on user initiated reload
- Reset the counter for a domain if the user has entered login data into the dialog and submitted
This would mitigate the DOS issue while hopefully not breaking any sites that rely on basic auth.
Differential Revision: https://phabricator.services.mozilla.com/D18019
--HG--
extra : moz-landing-system : lando
Casting non-void result to `void*` causes warning of clang. Additionally,
perhaps, we should use `Unused <<` because of modern style.
And also this patch makes widget/windows is treated as "warning as errors"
because this patch fixes the last warning.
Differential Revision: https://phabricator.services.mozilla.com/D17216
--HG--
extra : moz-landing-system : lando
For brevity, this is referred to as the "relative visual offset/transform"
in the code.
Differential Revision: https://phabricator.services.mozilla.com/D17725
--HG--
extra : moz-landing-system : lando
This helper will be reused for translating layers fixed to the RCD-RSF
with containerless scrolling.
Differential Revision: https://phabricator.services.mozilla.com/D17723
--HG--
extra : moz-landing-system : lando
This reflects the fact that it's no longer optional (the code path that
wouldn't pass one was removed with JPZC).
Differential Revision: https://phabricator.services.mozilla.com/D17722
--HG--
extra : moz-landing-system : lando
It is an implementation detail of GetCurrentAsyncTransformForFixedAdjustment().
Differential Revision: https://phabricator.services.mozilla.com/D17719
--HG--
extra : moz-landing-system : lando
It seems like we intermittently get fuzz on the clip-path-inset tests.
It's better for us to accept that fuzz than intermittently fail.
Differential Revision: https://phabricator.services.mozilla.com/D18277
--HG--
extra : moz-landing-system : lando
