When we encounter an error updating resources, or processing parent
commands, we actually bail out midway. This is problematic because some
resource updates and commands depend on follow-ups to release resources
and such. Also, when the next display list update comes in, we may now
have an incomplete resource set and see display errors / crashes that
may not be easily traceable to the previous failure.
This patch makes us always finish processing a transaction, even if we
encountered errors. This will put us in a more consistent state at
least. It adds new asserts to try to catch these issues sooner and in
automation. It also ensures we do a print to the critical log in all of
these cases so we know this issue was encountered.
Differential Revision: https://phabricator.services.mozilla.com/D135613
This is the main patch for the bug. It aims to change the grapheme cluster
break's `Next()` API by implementing SegmentIteratorUtf16 interface, and adapt
the callers. It shouldn't change the behavior.
While rewriting the caller, one caveat worth mentioning is the loop termination
condition. If the old code relies on `!AtEnd()` as the loop termination
condition, and it advances the iterator at the end of the loop, it meant
to *skip* its logic when the break position is at the end of the string. For
example, see the `mozTXTToHTMLConv::NumberOfMatches`.
This patch also hooks grapheme cluster break iterator into
Segmenter::TryCreate() interface.
Existing test coverage for the file changed:
- netwerk/test/unit/test_mozTXTToHTMLConv.js
- layout/reftests/forms/input/file/dynamic-max-width.html
Differential Revision: https://phabricator.services.mozilla.com/D135643
`Span` is more versatile than `const String&`, and existing callers passing a
String into this function do not need any change.
This patch makes the next part simpler.
Differential Revision: https://phabricator.services.mozilla.com/D135642
Include "nsLayoutUtils.h" in nsFileControlFrame to get rid of warnings in my
editor because it uses utilities such as `nsLayoutUtils::AppUnitWidthOfString`.
We compile it without issues because of unified build.
Differential Revision: https://phabricator.services.mozilla.com/D135640
This is essentially a partial revert of a cleanup done in bug 1742896. If canvas and content
are using the same underlying gfxDWriteFont and simultaneously retrieving a ScaledFont, this
may cause the ScaledFont to get repeatedly destroyed and re-instantiated every time we switch
from one context to the other. If this destruction happens at an inopportune time while WR
is still using a blob image with the font, it can potentially trigger undesirable assertions.
For now, duplicate the part of Bas' original patch from bug 1730722 that separatedly cached
the GDI and non-GDI versions of the ScaledFont. This way, both will exist for the lifetime
of the underlying gfxDWriteFont and thus avoid the thrashing.
Differential Revision: https://phabricator.services.mozilla.com/D135442
Not sure how this code came to be, but it produces an empty javadoc jar.
The patch fixes the javadoc jar task so that it actually collects the javadoc
files.
Differential Revision: https://phabricator.services.mozilla.com/D135752
`nsINode::ComputeIndexOf` may be expensive especially when the node is not
in the parent node. Therefore, `DetermineOffsetFromReference` should check
whether `mRef` has already been removed from the child node chain of `mParent`.
Then, it explains the reason why `ComputeIndexOf` may return `Nothing` clearer.
Depends on D135190
Differential Revision: https://phabricator.services.mozilla.com/D135823
`IsSetAndValid` method of `RangeBoundaryBase` and `EditorDOMPointBase` should
return `false` if points a removed node. However, while a node is being
removed, the node still keeps referring the parent, but it has already removed
from the child node chain of the parent. In this moment, returning `true` may
not be expected by the callers because the point becomes invalid soon with
the parent being cleared.
Differential Revision: https://phabricator.services.mozilla.com/D135190
It assumes that `mRef` is always in `mParent`, but this may be called when
`mRef` is **being** removed from `mParent`. In the case, `mRef` still thinks
`mParent` is its parent, but it's already been removed from the child node chain
of `mParent`. Therefore, `mParent->ComputeIndexOf(mRef)` may return `Nothing`.
This patch makes it keeps `mOffset` as `Nothing` in the case, and if the caller
wants invalid offset, this makes it use the fallback path. I.e., this patch
changes the behavior of `RangeBoundary::Offset(kValidOffset)`.
Differential Revision: https://phabricator.services.mozilla.com/D134678
Instead of relying on untrusted click/auxclick events anywhere
instantiating the actor, and then having to look for links, after this
patch we'll only instantiate the actor for actual link clicks. This
patch moves to using a chrome-only command event (with type
`chromelinkclick`) dispatched from the link click post-visitor
to accomplish that.
In future we should probably move both this and the
middle-click-to-paste handling into DOM code (or, for the latter,
remove it) but this is a less invasive solution.
This also moves the middle-click-to-paste handling into its own
listener. It needs to listen to page events in general (not just
links) but is disabled everywhere by default, so registering an
actor for everyone doesn't seem like a good trade-off. To avoid
duplicating all the logic (we do need to avoid doing middle-click
navigation based on the clipboard when clicking on links!), as
well as keeping patch size down, the actual control flow goes
through the click handler actor still.
Differential Revision: https://phabricator.services.mozilla.com/D134011
As historical reason, AndroidBridge has a lot of JNI wrappers. But we have
auto-generation JNI wrappers now, so it is unnecessary to keep wrappers in
AndroidBridge for GfxInfo.
So I would like to remove AndroidBridge dependencies from GfxInfo.
Differential Revision: https://phabricator.services.mozilla.com/D135324
The widget is the thing we care about here. The document/presshell/prescontext are fetched from the widget if we need them for something else. So we don't need to go widget -> prescontext -> presshell -> viewmanager -> rootview -> widget to get the window rendering, just fetch the window renderer right from the widget that we are already storing.
(This was pointed out in https://phabricator.services.mozilla.com/D135340 of bug 1749004 as a potential minor behaviour change of that patch.)
Differential Revision: https://phabricator.services.mozilla.com/D135440
Before an instance of a WindowGlobalMessageHandler is ready to be used the
initial session data needs to be applied. Because this happens asynchronously
an internal "window-global-handler-created" event will be used for which the
root message handler or any other module can listen for.
Differential Revision: https://phabricator.services.mozilla.com/D134265
There are two kind of events that can be used by module implementations
to pass information within the message handler framework.
First, with internal events the different modules and the message handlers
themselves can send around information eg. informing the parent process
about specific DOM events happening in the child process. These events
are not intended to be sent to external clients.
Second, with protocol events the different modules can send events with
a payload as specified in the appropriate protocol. These events shouldn't
be intercepted, modified, or ignored and will be sent to external clients.
Differential Revision: https://phabricator.services.mozilla.com/D134264
Change spelling in both network.http.http3.priorization and
network.http.http3.send_background_tabs_deprioritization config option
Differential Revision: https://phabricator.services.mozilla.com/D135689
nsPageSequenceFrame does a thing where it grows its desired size to fit the
AvailableISize and ComputedBSize (under the assumption that those are the
actual dimensions of our scrollport, which it wants to make maximal use of).
This behavior causes trouble when it's reflowed under the privileged
'sizeToContent' JS API. That API makes us reflow with nscoord_MAX as the
viewport's ComputedBSize(), and this nscoord_MAX value gets passed down to be
the nsPageSequenceFrame's ComputedBSize as well. When we reach the code in
question, we dutifully grow the desired size to that bogus huge value, which is
clearly wrong.
This patch addresses this issue by simply declining to grow the desired size in
the scenario where ComputedBSize() is unconstrained. This leaves us with
reasonable values for our desired size (which are actually based on the
content, which makes it the right thing to do for the purpose of a
SizeToContent() call).
Differential Revision: https://phabricator.services.mozilla.com/D135762
