Also, make the same change to nsPresContext::GetTextInputHandlingWidget and
TextComposition::GetWidget, which are essentially aliases/wrappers for this
function.
This patch shouldn't change behavior at all, aside from:
* optimizing away some redundant reference counting and widget-lookups
* delaying some nsIWidget::Release() calls, which will now happen after we're
actually done using the object, instead of happening when the getter
completes. (It's unlikely this impacts behavior, because there are other
objects that are keeping the nsIWidget instance alive.)
Motivation / "wins" from this patch:
* nsPresContext::GetRootWidget already works with a refcounted pointer
internally. Before this patch, it drops the reference before returning the
pointer. This is a bit suspect and would cause security issues, in the
unlikely event that this were the last strong reference to the object. It
can just as easily/efficiently transfer the strong reference to the caller,
and let the caller determine when to release it.
* Many of the callers were already storing the return value in nsCOMPtr, which
meant that they were incurring an additional AddRef/Release when
populating/destructing that smart pointer. Now they can just take ownership
of the already_AddRefed return value and avoid redundnat refcount-churn.
* For the callers that weren't storing the return value in nsCOMPtr, some of
them were calling this getter twice in a row (once to test for truthiness and
once to use the known-truthy value). This was wasteful, both from the
repeated lookup-work (since the function isn't a trivial getter), and from
repeated refcount-churn. This patch collapses these repeat-calls to a single
call, avoiding those inefficiencies.
Differential Revision: https://phabricator.services.mozilla.com/D127180
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
We don't use exceptions anyways, but having no warnings allows warning us when
warnings appear, so let's fix this.
Depends on D126939
Differential Revision: https://phabricator.services.mozilla.com/D126940
This patch combines three relatively small changes:
1) Removing string-based APIs
-- Adjusting the Sanitize() function, its WebIDl definition etc. to only
accept Document/DocumentFragment
2) Parse allowComments from the Sanitizer constructor and pass into the
underlying nsTreeSanitizer
3) Ensure that exceptions and error cases align with current wpt
Differential Revision: https://phabricator.services.mozilla.com/D126673
dom/base/CustomElementRegistry.cpp:580:56: error: loop will run at most once (loop increment never executed) [-Werror,-Wunreachable-code-loop-increment]
for (auto iter = mCandidates.Iter(); !iter.Done(); iter.Next()) {
^~~~~~~~~~~
Differential Revision: https://phabricator.services.mozilla.com/D126876
dom/quota/test/gtest/TestFlatten.cpp:18:3: error: loop will run at most once (loop increment never executed) [-Werror,-Wunreachable-code-loop-increment]
for (const auto& item : Flatten<int>(nsTArray<int>{})) {
^~~
dom/quota/test/gtest/TestFlatten.cpp:26:3: error: loop will run at most once (loop increment never executed) [-Werror,-Wunreachable-code-loop-increment]
for (const auto& item : Flatten<int>(nsTArray<CopyableTArray<int>>{})) {
^~~
dom/quota/test/gtest/TestFlatten.cpp:34:3: error: loop will run at most once (loop increment never executed) [-Werror,-Wunreachable-code-loop-increment]
for (const auto& item :
^~~
clang figures out that the loop is not going to execute, which is the
whole point of the test.
Differential Revision: https://phabricator.services.mozilla.com/D126874
dom/media/gtest/TestMediaDataEncoder.cpp:199:16: error: code will never be executed [-Werror,-Wunreachable-code]
result = Some(false);
^
`FAIL()` expands to an expression that starts with `return`, so the code
coming after it never runs.
Differential Revision: https://phabricator.services.mozilla.com/D126873
dom/media/mediacontrol/MediaStatusManager.cpp:260:13: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return u""_ns;
^~~
Differential Revision: https://phabricator.services.mozilla.com/D126871
dom/console/Console.cpp:2899:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return 0;
^
dom/console/Console.cpp:2955:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return 0;
^
dom/fetch/FetchDriver.cpp:252:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return NS_OK;
^~~~~
Differential Revision: https://phabricator.services.mozilla.com/D126870
Using requestedIndex on the child side is hard, because there are race conditions when a session history load is triggered
and at the same time a non-session history load commits a new active entry.
Differential Revision: https://phabricator.services.mozilla.com/D126619
dom/media/webrtc/MediaEngineDefault.cpp:102:3 [-Wunreachable-code-loop-increment] loop will run at most once (loop increment never executed)
dom/media/webrtc/MediaEngineDefault.cpp:547:7 [-Wunreachable-code] code will never be executed
dom/media/webrtc/common/browser_logging/WebRtcLog.cpp:29:16 [-Wunused-const-variable] unused variable 'default_log_name'
Differential Revision: https://phabricator.services.mozilla.com/D126755
Building with `ac_add_options --disable-unified-build` on macOS hits the following warnings-as-errors:
dom/media/GraphDriver.cpp:594:21: warning: code will never be executed [-Wunreachable-code]
dom/media/webaudio/blink/HRTFPanner.cpp:43:16 [-Wunused-const-variable] unused variable 'RenderingQuantum'
Differential Revision: https://phabricator.services.mozilla.com/D126754
Since we cannot really run aarch64 windows jobs on try, we're just going to
have to land this and see what happens.
Depends on D126414
Differential Revision: https://phabricator.services.mozilla.com/D126415
Previously we were staring `PBackground` in content processes in
response to receiving the `SetXPCOMProcessAttributes` IPC message, which
is sent immediately after the process is launched. Meanwhile, the
idle scheduler tries to use PBackground when the main thread considers
itself idle. But if thread scheduling is such that the content process
main thread becomes idle before the IPC I/O thread has received and
dispatched that message, then we have a problem (signaled by an assertion
failure).
This patch moves content process `PBackground` startup earlier, to the
end of `ContentProcess::Init`; that point is after enough of IPC and
XPCOM is started for it to work, but before we start spinning the main
thread event loop.
Differential Revision: https://phabricator.services.mozilla.com/D126144
Unsuppressing is done only if the page can use stylesheet cache. That should mean the
load isn't a cold load and also some other resources may be cached and thus
painting could happen sooner.
There is currently a regression around dom.ipc.processCount.webIsolated handling, but the
testing has been done with dom.ipc.processCount.webIsolated==1, and the patch for bug 1731792
should give back similar behavior as what process count 1 has.
Differential Revision: https://phabricator.services.mozilla.com/D125878
Previously we were staring `PBackground` in content processes in
response to receiving the `SetXPCOMProcessAttributes` IPC message, which
is sent immediately after the process is launched. Meanwhile, the
idle scheduler tries to use PBackground when the main thread considers
itself idle. But if thread scheduling is such that the content process
main thread becomes idle before the IPC I/O thread has received and
dispatched that message, then we have a problem (signaled by an assertion
failure).
This patch moves content process `PBackground` startup earlier, to the
end of `ContentProcess::Init`; that point is after enough of IPC and
XPCOM is started for it to work, but before we start spinning the main
thread event loop.
Differential Revision: https://phabricator.services.mozilla.com/D126144
dom/webauthn/WinWebAuthnManager.cpp(274,11): error: variable 'winAttestation' set but not used [-Werror,-Wunused-but-set-variable]
DWORD winAttestation = WEBAUTHN_ATTESTATION_CONVEYANCE_PREFERENCE_ANY;
^
dom/webauthn/WinWebAuthnManager.cpp(529,9): error: variable 'winAttachment' set but not used [-Werror,-Wunused-but-set-variable]
DWORD winAttachment = WEBAUTHN_AUTHENTICATOR_ATTACHMENT_ANY;
^
Differential Revision: https://phabricator.services.mozilla.com/D126449
Priviously, the ContentBlocking::ShouldAllowAccessFor() checkes don't
check if the storage permission was came from the allowList or not. This
patch changes that and it will check if the channel/window is
allowlisted at the same moment as checking the ContentBlockingAllowList.
It returns early if the channel/window is in the allowList.
Differential Revision: https://phabricator.services.mozilla.com/D126278
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
In D58392 and D58393, we already added some assertions to ensure that (1) sample is valid when it got added (2) sample is valid when we call `GetSample()`.
However, the crash still exists and doesn't hit these two places. So another possible situation is that samples become invalid during modification before we return it via `GetSample()`.
Therefore, add more assertion to see my guess is correct or not.
Differential Revision: https://phabricator.services.mozilla.com/D126722
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
Previously we would only include about: and moz-extension details
on Windows, because I erroneously thought that was the only place
we could sanitize them properly. But these types of URLs aren't
hard to sanitize, and really it's file:// URIs that are hard, and
those will stay windows only.
So now we collect about: and moz-extension: URIs on all platforms
and we additionally include whether the extension is privileged
or not.
We put them under new keys also.
Differential Revision: https://phabricator.services.mozilla.com/D126132
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
Actually, date, datetime-local and time won't set correct `mHTMLInputType`
in `InputContext` since focused `aContent` isn't input element on UAWidget.
Another attribute (`inputmode`) is still correct value since `IMEState` isn't
editable, even if this isn't fixed.
Differential Revision: https://phabricator.services.mozilla.com/D126576
We can use QM_TO_RESULT (instead of MOZ_TO_RESULT) because QM_WARNONLY_TRY
doesn't propagate errors, so no other adjustment is needed.
Differential Revision: https://phabricator.services.mozilla.com/D125314
* Remove test_webgl_conformance because we're always conformant now.
* Remove test_webgl_color_buffer_float because we have coverage in CTS
now.
Differential Revision: https://phabricator.services.mozilla.com/D126139
It does nothing with webrender enabled. Also remove
nsDOMWindowUtils::GetOMTCTransform, because it was only used from that
test.
Differential Revision: https://phabricator.services.mozilla.com/D126316
Before this change, in nsLayoutUtils::FrameIsScrolledOutOfViewInCrossProcess
we call BaseRect::IsEmpty() for the returned value of GetFrameVisibleRectOnScreen,
unfortunately if the returned value size is (0x0), BaseRect::IsEmpty() returns
true thus we misthink the given nsIFrame is out of the visible area of the OOP
iframe where the nsIFrame lives.
Note that we have already done the same check for in-process cases in
IsFrameScrolledOutOfView [1].
The test case in this change fails without this change, suceeds with
the change. Though, to be honest, I don't know the reason those styles
, `display: grid`, etc. generate (0x0) sized frame even if decendants have
sized.
[1] https://searchfox.org/mozilla-central/rev/15de05f0e6d841cbc2ac66f8dcad72ebdada47f6/layout/generic/nsIFrame.cpp#11090-11094
Differential Revision: https://phabricator.services.mozilla.com/D126312
By storing the PrincipalInfo in the parent copy it is possible to
query the BackgroundSessionStorageManager withouth the need of a
preprocessing step matching resulting data to principals using the
browsing context tree. Instead the result from the query contains the
principal info.
To be able to initialize the parent actor lazily with a principal
info, it was needed to make clearing the storage be a less fine
grained transaction. Instead of sending updates per cache, we after
clearing in the child process we send a message to the parent that in
turn performs the same steps.
Differential Revision: https://phabricator.services.mozilla.com/D125680
Before this change, in nsLayoutUtils::FrameIsScrolledOutOfViewInCrossProcess
we call BaseRect::IsEmpty() for the returned value of GetFrameVisibleRectOnScreen,
unfortunately if the returned value size is (0x0), BaseRect::IsEmpty() returns
true thus we misthink the given nsIFrame is out of the visible area of the OOP
iframe where the nsIFrame lives.
Note that we have already done the same check for in-process cases in
IsFrameScrolledOutOfView [1].
The test case in this change fails without this change, suceeds with
the change. Though, to be honest, I don't know the reason those styles
, `display: grid`, etc. generate (0x0) sized frame even if decendants have
sized.
[1] https://searchfox.org/mozilla-central/rev/15de05f0e6d841cbc2ac66f8dcad72ebdada47f6/layout/generic/nsIFrame.cpp#11090-11094
Differential Revision: https://phabricator.services.mozilla.com/D126312
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This adds an optional paper orientation to PrintPreviewResultInfo populates it
from the CSS page size when finishing print preview. The value is then placed
in the PrintPreviewSuccessInfo to be sent to the frontend.
Differential Revision: https://phabricator.services.mozilla.com/D124248