`Selection::Extend()` is too slow but editor and ContentEventHandler use it in
some places. We should make them use `Selection::SetStartAndEndInLimiter()` or
`Selection::SetBaseAndExtentInLimiter()`. The former is usable only when caller
guarantees the start point is prior to the end point in the DOM tree.
Otherwise, we need to use the latter even though it's slower than the former.
Differential Revision: https://phabricator.services.mozilla.com/D23462
--HG--
extra : moz-landing-system : lando
Right now we just block the image returned from nsIFrame::GetCursor, which is
the first loading cursor image.
I think we should do the same we do when the image fails to load, which is to
fall back to the next image instead.
This patch moves all the custom cursor code selection logic to
EventStateManager, and lets the frame return a CursorKind and whether custom
images are allowed.
Differential Revision: https://phabricator.services.mozilla.com/D23289
--HG--
extra : moz-landing-system : lando
Hiding document.createEvent("TouchEvent"), document.createTouch, document.createTouchList and ontouch* event
handlers on desktop to follow what Chrome has done.
This patch explicitly does not remove createTouch or createTouchList everywhere, although those seem to have been
removing already on some other browsers.
Devtools use TOUCHEVENTS_OVERRIDE_ENABLED for touch event testing, and this patch keeps the old behavior per discussion
with devtools devs.
Differential Revision: https://phabricator.services.mozilla.com/D22081
--HG--
extra : rebase_source : 562588a289632ba2f11db7f3ac8782c26c3b05f8
Only Firefox has an operation to paste clipboard data as quoted text
(Control + middle button paste). Input Events Level 1 and Level 2 declared
new inputType value for this operation. Therefore, we should support it.
Differential Revision: https://phabricator.services.mozilla.com/D22067
--HG--
extra : moz-landing-system : lando
`carriage return` and `space` are common keys which user might use to start media, so we should take account them as supported user gesture inputs.
As their pseudo char code are zero, we have to check their key code in order to distinguish them from other controls keys such as shift, alt...
Differential Revision: https://phabricator.services.mozilla.com/D21253
--HG--
extra : moz-landing-system : lando
These casts are now unnecessary after Part 2, due to all consumers directly
using `ContentParent`.
Depends on D20551
Differential Revision: https://phabricator.services.mozilla.com/D20552
--HG--
extra : moz-landing-system : lando
These casts are now unnecessary after Part 2, due to all consumers directly
using `ContentParent`.
Depends on D20551
Differential Revision: https://phabricator.services.mozilla.com/D20552
--HG--
extra : moz-landing-system : lando
DataTransfer should have more 2 constructors. One takes |const nsAString&| and
sets its data to the string. The other takes |nsITransferable*| and stores only
its data with DataTransferItem.
If given data is external resource like the case of `HTMLEditor::PasteTransferable()`,
we should copy its data to each DataTransferItem because nsITransferable is not
cycle-collectable, but DataTransfer may be grabbed by JS. Unfortunately, adding
new path to initialize DataTransfer with nsITransferable instance is too risky
because DataTransfer and DataTransferItem work together to initialize each of
them if DataTransfer is in external mode. Therefore, this patch makes the
new constructor temporarily sets it to in external mode, then, cache usable types
first, then, call `FillAllExternalData()` to make each DataTransferItem initializes
its data by itself, finally, make the constructor set it to internal mode and release
nsITransferable instance. This is ugly implementation but the most reasonable
way for now because:
- We don't need to change DataTransfer nor DataTransferItem a lot in this bug.
- We don't need to duplicate any code like a loop in `CacheExternalData()`.
In another bug, we should redesign DataTransfer and DataTransferItem to
make DataTransferable easier to be added new constructors.
Differential Revision: https://phabricator.services.mozilla.com/D19298
--HG--
extra : moz-landing-system : lando
InputEvent.dataTransfer is declared by Input Events Level 1 and Level 2 (i.e.,
not UI Events). It's necessary for "beforeinput" event on contenteditable
elements because of with some InputEvent.inputType values on contenteditable,
InputEvent.dataTransfer is used instead of InputEvent.data.
According to the Chrome's behavior, if InputEvent.dataTransfer is created by
web apps, the DataTransfer object is mutable. Otherwise, i.e., the event
represents user input, the DataTransfer object is read only. We should follow
this behavior.
This is enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D19296
--HG--
extra : moz-landing-system : lando
InputEvent.data notifies web apps of inserting/inserted text with "beforeinput"
and "input" events. So, this is important especially for "beforeinput" event
listeners. That's the reason why we need to support this before implementing
"beforeinput" event.
This patch adds it into InputEvent and make it enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D19285
--HG--
extra : moz-landing-system : lando
The actual subcategories will be added in later patches, so that there are no
unused categories.
Differential Revision: https://phabricator.services.mozilla.com/D11334
--HG--
extra : moz-landing-system : lando
re-enable many tests on windows 1803 due to invalid screen resolution whilst testing
Differential Revision: https://phabricator.services.mozilla.com/D19535
--HG--
extra : moz-landing-system : lando
When preceding mouse event is handled, that may cause changing style of the
target. Therefore, when an eMouseDown or eMouseUp event is handled, handlers
require the latest layout. Currently, nsViewManager::DispatchEvent() tries
to guarantee that with calling nsIPresShell::FlushPendingNotifications()
with FlushType::Layout. However, this just flushes the pending layout in
the PresShell associated with the nsViewManager instance. I.e., if the
target is in a child PresShell, its layout hasn't been flushed.
This patch makes PresShell::EventHandler::HandleEvent() flush pending
notifications at first of handling events using coordinates (only when
eMouseDown or eMouseUp, though). Then, when it realizes that the event
should be handled in a child PresShell, makes it flush its pending
notifications and then, recompute event target with the latest layout if
the layout is actually changed.
Differential Revision: https://phabricator.services.mozilla.com/D13720
--HG--
extra : moz-landing-system : lando
With these changes, XBL just runs in the window scope of whatever document it's
attached to. Since (outside of tests and "remote XUL") we no longer attach XBL
to web documents, this is fine. And "remote XUL" already ran without the XBL
scope.
Native anonymous content, which used to be placed in the XBL scope to hide it
from the page, is now placed in the unprivileged junk scope, so it stays hidden
from the page.
dom/xbl/test/test_bug944407.xul is being removed because we are changing the
behavior it's trying to test for. Since we now always put the XBL in the same
scope as the page, script is enabled for the XBL if and only if it's enabled for
the page.
dom/base/test/test_bug419527.xhtml, dom/events/test/test_bug391568.xhtml,
dom/xbl/test/test_bug1086996.xhtml are being switched to a chrome test because
otherwise the XBL can't see the getAnonymousNodes method.
All the XBL bits are being removed from test_interfaces because we no longer
have a separate XBL scope to test the behavior of.
js/xpconnect/tests/mochitest/test_nac.xhtml is being removed because XBL no
longer has access to NAC unless the page it's attached to does too, so the test
doesn't really make sense.
layout/xul/test/test_bug1197913.xul is being switched to a chrome test because
its XUL elements use bindings that rely on APIs that are not exposed to normal
web content.
layout/reftests/bugs/495385-2f.xhtml is being removed because I can't think of
a sane way to test that in the new world, short of running the reftest as
chrome. And it doesn't seem worthwhile to look for a way to do that.
dom/xbl/test/test_bug1098628_throw_from_construct.xhtml now needs to
expectUncaughtException(), because the exception is now being thrown in Window
scope.
dom/xbl/test/test_bug1359859.xhtml needs to expectUncaughtException() as needed
and not use XPCNativeWrapper (which it doesn't need to anyway now).
dom/xbl/test/test_bug389322.xhtml, dom/xbl/test/test_bug400705.xhtml,
dom/xbl/test/test_bug401907.xhtml, dom/xbl/test/test_bug403162.xhtml,
dom/xbl/test/test_bug526178.xhtml, dom/xbl/test/test_bug639338.xhtml don't need
to use XPCNativeWrapper anymore.
dom/xbl/test/test_bug821850.html is being removed because it exists only to test XBL scopes.
dom/xbl/test/file_bug950909.xml is being changed to work without a separate XBL
scope (though whether the test still makes sense at that point is a bit questionable).
Differential Revision: https://phabricator.services.mozilla.com/D19260
--HG--
extra : moz-landing-system : lando
It was added in bug 1461696 probably for tracking whether bug 1460295
is a wide-spread issue or so. This deprecation was already part of
deprecated mutation event, so it's never output to console. It was
added purely for getting telemetry.
Given that related issues are now fixed, we no longer needs this.
Differential Revision: https://phabricator.services.mozilla.com/D18935
--HG--
extra : moz-landing-system : lando
And for now, start blocking custom cursors that are larger than 64 pixels.
I wish I knew how to add a test for this, but I tested manually using the
test-case from bug 1518189 with and without hidpi.
We always treat the cursor image size as CSS pixels (and upscale it to device
pixels in HiDPI). We have bugs to stop doing that though (bug 1425694).
Differential Revision: https://phabricator.services.mozilla.com/D18671
--HG--
extra : moz-landing-system : lando
Old Confluence does not aware of conflated model keypress event (see UI Events
spec, https://w3c.github.io/uievents/#determine-keypress-keyCode).
Additionally, Confluence can be hosted with any domains. Therefore, we cannot
use blacklist to disable the conflated model keypress event only on it.
This patch checks whether current or parent document is Confluence with JS
module, called KeyPressEventModelCheckerChild. For kicking this module,
nsHTMLDocument dispatches an custom event, CheckKeyPressEventModel, when it
becomes editable only first time. Finally, if it's a Confluence instance, the
module let PresShell know that we need to use split model keypress event in it.
Differential Revision: https://phabricator.services.mozilla.com/D17907
--HG--
extra : moz-landing-system : lando
This cleans up a bit and allows us to be smarter about which cursors
should we allow from content or what not, which will help with bug 1445844 and
co.
Differential Revision: https://phabricator.services.mozilla.com/D16711
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
When user middle clicks a link, most users must not expect to expose clipboard
content to the web application. Therefore, we should stop firing paste event
when user click a link with middle button.
This patch makes ClickHandlerChild.handleEvent() prevent multiple action
when it posts middle click event on a link. Note that even if middle click
event is consumed, default event handler will dispatch paste event.
Unfortunately, this is compatible behavior with the other browsers.
Therefore, we cannot change this behavior with calling preventDefault() and
this is the reason why this patch adds Event.preventMultipleActions().
Out of scope of this bug though, if there is an element which looks like a
link but implemented with JS, web apps can steal clipboard content if user
enables middle click event and user just wants to open the link in new tab.
It might be better to stop dispatching paste event in any browsers and request
to change each web apps.
Differential Revision: https://phabricator.services.mozilla.com/D17209
--HG--
extra : moz-landing-system : lando