This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Holding a weak pres context pointer across stuff that does flushes is dangerous.
Hopefully, we just poke at it when we find a frame (thus a pres context should
be around, and it rather be the one that we started poking at).
I think it'd be better to just not keep the member around, since frames can
reach the pres context easily.
MozReview-Commit-ID: HcepvzcSsaH
--HG--
extra : rebase_source : 5d0ffb1502e64f8010b7aea714a4caf762c9a95e
Similar to TextInputListener, EditorBase should store IMEContentObserver
directly instead of via nsIEditorObserver. Then,
EditorBase::NotifyEditorObservers() can call each method directly.
Additionally, we can make IMEContentObserver not derived from nsIEditorObserver.
MozReview-Commit-ID: cNKWJe5eUC
--HG--
extra : rebase_source : 4ed3b3b3180b8ee4a7c514ce1f89eba4dad64fbe
This allows us to maintain the pre-existing but not-asserted-before invariant of
not doing layout on documents in the BFCache.
The simpler fix here is something like:
if (nsIDocument* doc = mPresShell->GetDocument()) {
doc->FlushPendingNotifications();
}
But referencing the document looks cleaner on most callsites I think. I can just
do the above if you prefer.
MozReview-Commit-ID: L4pTRW3eMAf
--HG--
extra : rebase_source : 466d3eee973f2f14ce0964162e5f7f2f1c2bfc63
This patch makes EditorBase derived from nsISelectionListener. Then, we can
make IMEContentObserver, TextInputListener, ComposerCommandsUpdater,
TypeInState not derived from nsISelectionListener since EditorBase or
HTMLEditor can notify them of selection change directly. Additionally,
ResizerSelectionListener is not necessary anymore since it just implements
nsISelectionListener and calls only a method of HTMLEditor. So, HTMLEditor
can call it directly.
Note that the order of selection listeners may be different. However,
according to what each selection listener does, changing the order isn't
problem.
MozReview-Commit-ID: 1JXZxQcS0tP
--HG--
extra : rebase_source : c2ebe622a74001ad4e421da492dcdab8e6fe1649
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
Most of the Shadow DOM related code are behind "dom.webcomponents.enabled" and
this pref is only used by Shadow DOM right now, so we should rename it to
"dom.webcomponents.shadowdom.enabled"
MozReview-Commit-ID: er1c7AsSSW
In order to write tests, I would like to create an method that allows chorome js can directly set the user-activation flag.
Therefore, I need to move all these details into nsDocument, then we could easily simulate the user activation.
MozReview-Commit-ID: 5JrCoQc0vF7
--HG--
extra : rebase_source : 256ff2993ef754dc51409e7e444b868a3302bd65
For top level frame, it should also be activated when user activate its child frame.
eg. A (youtube.com) -> B (ad.com), when user activate B frame, the A frame would also be activated.
MozReview-Commit-ID: BP7eGKiqYJe
--HG--
extra : rebase_source : 8a07e2a46d70957989168a9ee677e5241fee61fe
The event targets of touch events are not necessarily to be the same as their corresponding pointer events. So we don't have to cache the event target of pointer events when they are generated from touch.
MozReview-Commit-ID: 9Gd6ion7NXf
EditorBase::CreateTxnForComposition() just hides what it does. For its caller,
creating a factory method, CompositionTransaction::Create(), is clearer what
it does.
Additionally, capsuling the creation in CompositionTransaction class can make
the text node information in TextComposition updated automatically. So, now,
it might be better to update them in DoTransaction() because there is a lag
between creating the transaction and calling DoTransaction(). However, this
patch doesn't want to change any existing behavior. So, this doesn't fix this
issue.
MozReview-Commit-ID: K8ci7ytwh1u
--HG--
extra : rebase_source : d468a0fc997c99f78f7eb46451082e7f1e052890
There may be some pending input events in the queue of thread when content starts a dnd operation. Spec says that input events should be suppressed when there is a dnd operation. Add a flag in ESM and turn on/off when start/finish a dnd operation. Checking the flag in PresShell::HandleEvent because we may start a dnd operation with pointermove and we want to suppress the mousemove as well.
MozReview-Commit-ID: 43NZrA7SW4c
We implement PointerEvent.getCoalescedEvents as
1. Clone the widget events we coalesced.
2. Convert them to dom::PointerEvent when user calls getCoalescedEvents.
MozReview-Commit-ID: 8IKw4PbUsDD
EditorBase stores a text node, offset in it and length in it of composition
string directly. However, this wastes memory space if user never uses IME
or user only sometimes uses IME. Additionally, storing all data in
TextComposition is better than current design when other classes like
CompositionTransaction wants some information of both EditorBase and
TextComposition.
This patch moves those 3 members from EditorBase to TextComposition.
MozReview-Commit-ID: 4N7wmGGfxmt
--HG--
extra : rebase_source : bd7cb37fe9631b959ec21da40c20751fec269dca
We should follow the real use cases to synthesize mouse or touch events to generate pointer events so that the related logic is covered by these test cases.
MozReview-Commit-ID: 9xSgjSL0Azt
We should follow the real use cases to synthesize mouse or touch events to generate pointer events so that the related logic is covered by these test cases.
MozReview-Commit-ID: 9xSgjSL0Azt
According to the log in crash reports, eCompositionCommitRequestHandled is
sent to ContentCacheInParent twice or more for a composition. This causes
breaking mPendingCompositionCount and mPendingEventsNeedingAck management.
Currently, nsIWidget::NotifyIME() should be called only by
TextComposition::RequestToCommit(). Therefore, the method should manage if
it should request it actually. If the composition has already received
eCompositionCommit(AsIs) event, it shouldn't request it because parent process
may have already stated new composition and it shouldn't be broken by request
for old composition.
MozReview-Commit-ID: 2ekSa6EIeRP
--HG--
extra : rebase_source : d23aa29ce7871e83b99cec8c15aff0c580e08fb4
This flag would be used to help us decide whether website could be allowed the autoplay.
The media related implementation would be implemented in bug1382574.
MozReview-Commit-ID: GGIauBufs5A
--HG--
extra : rebase_source : c407ceed311fc3fb0140e5da44fd69e457a5098f
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
Currently, widget doesn't show VKB when input context change is caused by JS.
However, if it's caused by an event handler of a user input, user may expect
to open VKB. For example, if a touch event in fake editor causes moving
focus to actual editable node, user expect to show VKB.
Therefore, InputContextAction should declare two causes. One is unknown but
occurred during handling non-keyboard event. The other is unknown but occurred
during handling keyboard event.
However, EventStateManager doesn't have an API to check if it's being handling
a keyboard event. Therefore, this patch adds it first.
AutoHandlingUserInputStatePusher sends event type to StartHandlingUserInput()
and StopHandlingUserInput() of EventStateManager and sUserKeyboardEventDepth
manages the number of nested keyboard event handling. Therefore,
EventStateManager::IsHandlingKeyboardInput() can return if it's handling a
keyboard event.
IMEStateManager uses this new API to adjust the cause of changes of input
context.
Finally, InputContextAction::IsUserInput() is renamed to IsHandlingUserInput()
for consistency with EventStateManager and starts to return true when the
input context change is caused by script while it's handling a user input.
MozReview-Commit-ID: 5JsLqdqeGah
--HG--
extra : rebase_source : 9fcf7687d1bf90eeebbf6eac62d4488ff64b083c
