This change allows associating individual web progress events with which frame
they originate from, rather than only recording the `isToplevel` information as
we were before, which is necessary in order to use the OnLocationChange events
from content to track the current URI on CanonicalBrowsingContext.
Due to events in ContentChild being filtered through nsBrowserStatusFilter, some
of the callbacks will never be passed nsIRequest or nsIWebProgress pointers, and
this patch also simplifies them by removing information which is not necessary
from the IPC message.
Finally, this patch adds a number of checks to the relevant Recv callbacks in
the parent process which help ensure that it does not accept web progress events
from a content process which is no longer hosting the target BrowsingContext.
This may allow for us to stop manually suspending web progress events on process
switches, as these checks will handle this automatically based on the existing
BrowsingContext and WindowContext objects.
Differential Revision: https://phabricator.services.mozilla.com/D105556
The check in this function was added in bug 82236 to avoid an issue in the
mozilla suite where the UI would update to a subframe's URI. This came up
previously in bug 1206879 when we observed we weren't sending OnLocationChange
events when we were expecting, which was causing issues for pushState location
changes. A workaround was added in that bug to avoid the issue for the specific
case of pushState.
This patch removes the redundant check, and reverts the workaround added in that
bug. Unfortunately, we aren't able to fully remove nsISHEntry::GetIsSubframe, as
it is now used by Browser{Parent,Child}::CanCancelContentJS.
Differential Revision: https://phabricator.services.mozilla.com/D105555
With the changes in this patch stack, it will become more common for frontend
code to receive onLocationChange notifications for subframes, as we will now
correctly report events for oop subframes, and will also deliver notifications
for the first document loaded in subframes in order to update the current remote
URI on CanonicalBrowsingContext.
This change makes more of the callbacks fired by onLocationChange be guarded by
the isTopLevel check, including setting the "URL" crash annotation and updating
the macOS touchbar, which should hopefully both fix existing latent bugs, and
ensure that these issues don't occur with the more frequent onLocationChange
callbacks.
Differential Revision: https://phabricator.services.mozilla.com/D105554
When "build targets" are used, the sccache server isn't
being used/integrated properly with make.
By moving rusttests to a separate build "application",
`client.mk` is invoked normally, and sccache is happy.
* Move rusttests to a new build "application".
* Move and denormalize rusttests mozconfigs. The new rusttests
mozconfigs should expand to be mostly identical to their old
versions, except with `MOZ_AUTOMATION_*=0` and
`--enable-application=tools/rusttests`.
They will differ a bit from their old variants because some
of them originally didn't source from their
respective `$app_mozconfigs/common`.
* Modify `baseconfig.mk` to change tiers if running rusttests.
* Adjust CI config to use new "rusttests" build application.
Differential Revision: https://phabricator.services.mozilla.com/D106294
We already know the project name, we should unbundle it
from the project path.
This change is possible due to the work in 1664083,
and puts us back to the state before 1255185.
Differential Revision: https://phabricator.services.mozilla.com/D106293
It supports installing Mozilla applications with mozinstall, and simply running the thing it was instructed to download.
Differential Revision: https://phabricator.services.mozilla.com/D107543
This was used to ensure no cross-compartment objects were embedded by
ShapeGuardProtoChain (used for the property-not-found case) but that's no longer
an issue because ShapeGuardProtoChain only does shape guards now.
Note: for the property-found case, the cross-compartment issue still applies but
that's handled by SlotReadType::CrossCompartment.
Differential Revision: https://phabricator.services.mozilla.com/D107420
We already peeled off the receiver for non-delegates (= most objects) but we can
do this for delegates too.
Depends on D107418
Differential Revision: https://phabricator.services.mozilla.com/D107419
Eagerly marking prototypes as delegate resulted in a lot of unnecessary shadowing
checks and reshaping when initializing the properties of those objects. This is
a regression from bug 724768.
It's more efficient, simpler, and consistent with JS-defined objects to mark
objects as delegate when they become the prototype of another object.
This removes the check for delegates in EmptyShape::ensureInitialCustomShape. That
should be fine because the only object it applies to is String.prototype and it
doesn't affect correctness. (RegExp and Error prototypes are plain objects since
bug 1213341 and bug 1192038 so don't show up there anyway.)
Depends on D107417
Differential Revision: https://phabricator.services.mozilla.com/D107418
This goes back to bug 787856 but dynamic prototypes don't need to be marked as
delegate, because shape teleporting and JITs don't optimize those prototype chains.
Other proxy handlers such as ScriptedProxyHandler, ForwardingProxyHandler, Xrays
don't do this so this is also more consistent.
Depends on D107416
Differential Revision: https://phabricator.services.mozilla.com/D107417
This goes back to when shape teleporting was used for environment chains too.
See also bug 1608034 where we made this change for (other) environment objects.
The global has a lot of properties and this avoids doing unnecessary work to
invalidate teleporting.
Add Object.prototype to the test-JSObject GDB test so that we still have a test for
the delegate flag.
Differential Revision: https://phabricator.services.mozilla.com/D107416
The change to dom/base/nsFrameLoaderOwner.cpp is to log about the issues but still ensure we don't crash.
I'd prefer to not put error loads to bfcache.
Differential Revision: https://phabricator.services.mozilla.com/D107300
This method is asynchronous but misses the "await" statement.
As such it can cause race conditions in the "WebDriver:NewSession"
command.
Differential Revision: https://phabricator.services.mozilla.com/D107430
Always getting a user prompt shown when debugging code in Marionette
is disturbing. Given that we usually use the "debugger;" statement
anyway, this prompt will not be useful by default.
But we should keep it to actually allow users of Marionette and
geckodriver to run a debug session without having to modify the
code first.
Differential Revision: https://phabricator.services.mozilla.com/D107428
We are currently receiving tabDetached for content process targets
when we destroy them via:
Services.ppmm.broadcastAsyncMessage("debug:destroy-process-script")
done from process-helper and we stop watching for process targets.
Tests now depends on this behavior.
So I'm trying to replicate this behavior in order to later get rid of tabDetached
in favor of target-destroyed-form.
Differential Revision: https://phabricator.services.mozilla.com/D107248
This is a workaround, until the top level target uses the JSWindowActor codepath.
This will help get rid of tabDetached in favor of target-destroyed-form.
Differential Revision: https://phabricator.services.mozilla.com/D107246
The `beforeFn` and `afterFn` may cause some pending reflow. Then, synthesizing
arrow keys or mouse button events causes flushing the layout. At this time,
autocomplete popup may be closed with different reason and that may cause
unexpected login database.
Depends on D107172
Differential Revision: https://phabricator.services.mozilla.com/D107173
We're no longer collecting Email data for crash reports so this removes the
Email field and related bits from the main process crash reporters for Linux,
Mac, and Windows.
For Mac, I didn't remove the email-related fields, but instead hid them. In
order to remove them, I need to use an old xcode ibuilder to edit the .nib
files and we don't have that. Bug #1696164 covers updating the crash reporter
interface files on mac.
Differential Revision: https://phabricator.services.mozilla.com/D107251
We use it for the awesomebar outline so I think it makes sense, it certainly
feels off to have a blue tab line but an accent-colored outline.
Differential Revision: https://phabricator.services.mozilla.com/D107626