Editor creates a `<br>` element when it's root element is empty.
Then, it's stored by `TextEditRules::mBogusNode` and used for checking
whether the editor is empty quickly. However, this `<br>` element has
`mozeditorbogusnode` attribute whose value is `true`. However, adding or
removing the attribute is not cheap and web apps can refer such illegal
attribute.
Therefore, this patch makes `HTMLBRElement` take a specific flag whether
it's a bogus node or not. However, this means that this hacky thing will be
exposed outside editor module. For making what is the bogus node clearer,
this patch calls the such `<br>` elements as "padding `<br>` element for
empty editor". So, this patch also includes a lot of renaming methods and
variables, and modifying related comments.
Differential Revision: https://phabricator.services.mozilla.com/D39857
--HG--
extra : moz-landing-system : lando
pdfs should not have a way to exfiltrate the true device pixel ratio,
so it is safe to provide the correct value, enabling them to be rendered
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D39994
--HG--
extra : moz-landing-system : lando
Normally, the OuterDocAccessible is created first and the DocAccessibleParent for a remote document is created after that.
So, we get the OuterDocAccessible and call DocAccessibleParent::SendParentCOMProxy when the DocAccessibleParent is constructed (BrowserParent::RecvPDocAccessibleConstructor).
However, sometimes, the OuterDocAccessible is created *after* the DocAccessibleParent.
This sometimes happens for extension popups, for example.
In that case, we previously never sent the parent COM proxy.
Aside from leaving the remote document with a null parent, this also meant we never sent any events for the document, since events are buffered for remote documents until the parent COM proxy is received.
This effectively left the remote document (e.g. extension popup) inaccessible.
Now, we also call SendParentCOMProxy in the OuterDocAccessible constructor.
Note that this doesn't result in duplicates because if the OuterDocAccessible was created first, there won't be a DocAccessibleParent for the remote document yet, so this code won't run.
That said, if the OuterDocAccessible is recreated (e.g. due to frame reconstruction), we may call SendParentCOMProxy again.
This should be okay, but it required an assertion in DocAccessibleChild::RecvParentCOMProxy to be tweaked.
Differential Revision: https://phabricator.services.mozilla.com/D40358
--HG--
extra : moz-landing-system : lando
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
--HG--
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-001.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-002.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-span-all-rule-001.html.ini
extra : moz-landing-system : lando
Previously, we expected that we'd always be able to get the COM proxy for the parent (outer doc), so we crashed if it was null.
For an out-of-process iframe, this sometimes fails.
That is probably because the outer doc died in the embedder process, but the parent process hasn't received a message to remove it from the ProxyAccessible tree yet.
Differential Revision: https://phabricator.services.mozilla.com/D40150
--HG--
extra : moz-landing-system : lando
calling SetFakeCpuCount may cause GlobalHelperThreadState to create more threads than there are JSContexts in the list. This adds a function to check the length of the context list against the new thread count, and if there are not enough JSContexts, append more to the list.
Differential Revision: https://phabricator.services.mozilla.com/D39986
--HG--
extra : moz-landing-system : lando
ipc_message_utils.h defines IPDLParamTraits on windows for some things like
HWND and HANDLE. However, it doesn't directly include windows.h on Windows to
include them. All other usages seem to rely on including base/process.h, which
does include windows.h and adds the appropriate typedefs.
Differential Revision: https://phabricator.services.mozilla.com/D35089
--HG--
extra : moz-landing-system : lando
This change gives us the ability to selectively turn on cross-language
PGO, just like we have the ability to selectively turn on cross-language LTO.
There is room for things to go wrong here: it's not guaranteed that
`--enable-profile-generate=cross` will always be used with
`--enable-profile-use=cross`. Nothing bad will happen in the sense that
the build will succeed, but it's possible that we miss out on
optimizations on the Rust side. Either we fail to generate profile data
for the Rust code, or the Rust compiler fails to use the profile data.
In the future, we may want to default to cross-language PGO to avoid
these kind of mismatches.
Differential Revision: https://phabricator.services.mozilla.com/D39727
--HG--
extra : moz-landing-system : lando
Refactors get_clip_result_complex to cover ClipOut cases for rectangles as well
as Clip for non-repeated images.
Differential Revision: https://phabricator.services.mozilla.com/D40094
--HG--
extra : moz-landing-system : lando
This might seem like we are including the parent scale twice because it is also included in mInheritedTransform but FrameLayerBuilder::ChooseScale only incorporates the passed in scale when combining it with a scale computed purely based on the local transform induced by this stacking context item.
This also fixes bug 1564698 and doesn't regress bug 1495163 (the only testcase I can still find for the regressing bug, bug 1415987).
Differential Revision: https://phabricator.services.mozilla.com/D39867
--HG--
extra : moz-landing-system : lando
Before this change, AltGr+Enter wouldn't open url in new tab on non-English layouts on Windows. This happened because non-English layouts generated AltGr event on pressing right Alt key. Checking for this event in _whereToOpen function fixes the issue.
Differential Revision: https://phabricator.services.mozilla.com/D39466
--HG--
extra : moz-landing-system : lando
This change is necessary in order to support named targeting of remote
BrowsingContexts, since the current arrangement only supports in-process
contexts. It also considerably simplifies the logic, since named targetting is
now restricted to the same TabGroup/BrowsingContextGroup, which in and of
itself guarantees that origin attributes will always match in the cases that
we care about.
Differential Revision: https://phabricator.services.mozilla.com/D39991
--HG--
extra : rebase_source : 77795886ef762bd778ddd782608ffca294b7aee0
`IShellWindows::FindWindowSW` may return the dreaded `S_FALSE`, so we need to
ensure that we're handling that.
I checked the remaining functions called by this code and none of the others
do this; this is the only call site that requires the check.
I'm not sure why we're seeing this error code. I added an explicit cast to
ensure that `CSIDL_DESKTOP` is being interpreted as an `int`, though I doubt
that this actually makes any difference.
Differential Revision: https://phabricator.services.mozilla.com/D39799
--HG--
extra : moz-landing-system : lando