Same underlying reason as the comment before.
Also remove the XBL special case since XBL is no more.
Differential Revision: https://phabricator.services.mozilla.com/D52060
--HG--
extra : moz-landing-system : lando
The following tests are not removed and need to be ported to Shadow DOM:
- test_bug330925.xhtml
- test_bug372086.html
- test_bug319374.xhtml
Differential Revision: https://phabricator.services.mozilla.com/D50650
--HG--
extra : moz-landing-system : lando
`uint32_t`, because `nsRange::ComparePoints` requires it -- by webidl
interface -- to be unsigned long.
Moreover it makes `RangeBoundaryBase`'s interface cleaner, because it
already exposes the offset as a `uint32_t`.
Differential Revision: https://phabricator.services.mozilla.com/D50054
--HG--
extra : moz-landing-system : lando
Where possible I ported tests to use the shadow DOM. The following could
potentially be ported, but don't think it worth of it:
test_bug414907.xul - uses children nodes in constructor which is very
different in shadow DOM world
test_bug233643.xul - really tests XBL behavior
test_anonymous_content.py - bug on file already to create shadow DOM
test from scratch
Differential Revision: https://phabricator.services.mozilla.com/D49341
--HG--
rename : devtools/client/inspector/test/browser_inspector_highlighter-xbl.js => devtools/client/inspector/test/browser_inspector_highlighter-custom-element.js
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They
weren't quite good because:
1. While loading an iframe, they were being registered twice with the same
ids(for about:blank and the real URL) sometimes.
2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child
processes if the parent is in a different process. That may not be the case for
now, but it will be after fission.
So we had to find other IDs to:
1. Determine the Tab of the frames.
2. Determine the URLs of the frames.
For the first use case, we were using nsDocShell::mHistoryId for that purpose
but that was wrong. The closest thing that we can get to a tab ID is
BrowsingContext ID because they don't change after a navigation. But iframes
have different BrowsingContext's, so we still need to create a tree to
construct a tab content. That can be either in the front-end or capture time.
For the second use case, we were using a key pair of mHistoryId and mOSHE. We
now chose to keep inner window IDs for that purpose. Inner window IDs are
unique for each navigation loads because inner window correspond to each JS
window global objects. That's why we can use that without any problem. But one
problem is that we cannot handle `history.pushState` and `history.replaceState`
changes with that change since window global objects won't change during those.
But that was the best thing we can do after fission. So this will be a small
sacrifice for us to keep that functionality working after fission.
In that patch we also remove the registration/unregistration calls. We are
going to add those calls in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D47065
--HG--
extra : moz-landing-system : lando
Chrome and old Edge at least seem to have this behavior, and this way the testcase on the bug doesn't trigger click anymore since
we enter dnd mode and get dragleave etc. events.
Manually tested on linux and Windows, and annyg tested on Mac
Update test_dragstart.html's draggable=true test to follow the pattern used by other tests
Differential Revision: https://phabricator.services.mozilla.com/D48208
--HG--
extra : moz-landing-system : lando
Chrome and old Edge at least seem to have this behavior, and this way the testcase on the bug doesn't trigger click anymore since
we enter dnd mode and get dragleave etc. events.
Manually tested on linux and Windows, and annyg tested on Mac
Differential Revision: https://phabricator.services.mozilla.com/D48208
--HG--
extra : moz-landing-system : lando
This mostly updates the bindings to the current state.
No actual logic backing them yet.
*Note*: the IDL does *not* need to be checked for matching the upstream spec precisely at this stage. The upstream is evolving, we just need to update in order to start integrating the implementation. What needs to be checked is - how C++ represents the IDL, esp with regards to derived classes, events, and hierarchies.
The trickiest points, arguably, are:
- WebGPU -> GPU prefix change
- the goop for interfaces that are not final
Differential Revision: https://phabricator.services.mozilla.com/D46166
--HG--
rename : dom/webgpu/InputState.cpp => dom/webgpu/DeviceLostInfo.cpp
rename : dom/webgpu/Fence.h => dom/webgpu/DeviceLostInfo.h
rename : dom/webgpu/BlendState.cpp => dom/webgpu/OutOfMemoryError.cpp
rename : dom/webgpu/LogEntry.h => dom/webgpu/OutOfMemoryError.h
rename : dom/webgpu/BindGroup.h => dom/webgpu/ProgrammablePassEncoder.cpp
rename : dom/webgpu/BlendState.cpp => dom/webgpu/RenderBundle.cpp
rename : dom/webgpu/BlendState.h => dom/webgpu/RenderBundle.h
rename : dom/webgpu/AttachmentState.cpp => dom/webgpu/ValidationError.cpp
rename : dom/webgpu/AttachmentState.h => dom/webgpu/ValidationError.h
extra : moz-landing-system : lando
This mostly updates the bindings to the current state.
No actual logic backing them yet.
*Note*: the IDL does *not* need to be checked for matching the upstream spec precisely at this stage. The upstream is evolving, we just need to update in order to start integrating the implementation. What needs to be checked is - how C++ represents the IDL, esp with regards to derived classes, events, and hierarchies.
The trickiest points, arguably, are:
- WebGPU -> GPU prefix change
- the goop for interfaces that are not final
Differential Revision: https://phabricator.services.mozilla.com/D46166
--HG--
rename : dom/webgpu/InputState.cpp => dom/webgpu/DeviceLostInfo.cpp
rename : dom/webgpu/Fence.h => dom/webgpu/DeviceLostInfo.h
rename : dom/webgpu/BlendState.cpp => dom/webgpu/OutOfMemoryError.cpp
rename : dom/webgpu/LogEntry.h => dom/webgpu/OutOfMemoryError.h
rename : dom/webgpu/BindGroup.h => dom/webgpu/ProgrammablePassEncoder.cpp
rename : dom/webgpu/BlendState.cpp => dom/webgpu/RenderBundle.cpp
rename : dom/webgpu/BlendState.h => dom/webgpu/RenderBundle.h
rename : dom/webgpu/AttachmentState.cpp => dom/webgpu/ValidationError.cpp
rename : dom/webgpu/AttachmentState.h => dom/webgpu/ValidationError.h
extra : moz-landing-system : lando
The previous change is wrong because the sender shouldn't send selection change
notification if `IMEContentObserver` does not receive text change notifications
nor selection change notifications.
This patch reverts the change in the if block of previous change and instead
sets `IMEContentObserver::mNeedsToNotifyIMEOfSelectionChange` to `true` if
the sender sends a text change notification. (Note that even if there is
another text change with a mutation event listener, we need to send selection
change notification later so that this must be the right approach.)
Differential Revision: https://phabricator.services.mozilla.com/D47564
--HG--
extra : moz-landing-system : lando
Actually, CAUSE_UNKNOWN_CHROME is set when caller is chrome process. I would
like to change that this value is called from chrome or native.
Differential Revision: https://phabricator.services.mozilla.com/D44104
--HG--
extra : moz-landing-system : lando
`IMEContentObserver` sends selection change notification only when it receives
a DOM `Selection` change notification received. However, selection range in
plaintext offset may be changed when changing previous content of caret is
changed. In this case, currently we notify IME of only text change and
that causes IME keep caching selection offsets in previous content. This
causes IME queries character rect out of bounds. Therefore, even if
`IMEContentObserver` hasn't received DOM `Selection` change notification,
it should recompute selection range and if it's changed, it should notify
IME of selection change too.
Differential Revision: https://phabricator.services.mozilla.com/D46251
--HG--
extra : moz-landing-system : lando
This avoids relying on the accessibility.tabfocus
pref having been set by a previous test.
Differential Revision: https://phabricator.services.mozilla.com/D46374
--HG--
extra : moz-landing-system : lando