This is a big step in order to merge both.
Also allows to remove some very silly casts, though it causes us to add some
ToSupports around to deal with ambiguity of casts from nsIDocument to
nsISupports, and add a dummy nsISupports implementation that will go away later
in the series.
Differential Revision: https://phabricator.services.mozilla.com/D15352
Just use nsTArray. They're used to keep an array of strong references to
documents, and never use nsISupports-specific methods.
Plus they're are allocated on the stack so it should be safe to access them via
ranged for, so do that.
This is needed because nsCOMArray<T> depends on the cast from T to nsISupports
not to be ambiguous. I could fix that if needed, but it seems easier to just not
use it in these two cases.
Differential Revision: https://phabricator.services.mozilla.com/D15351
This will be needed for the next patches since the cast from nsIDocument* to
nsISupports* will become ambiguous, and I don't really want to replace all users
of nsCOMPtr<nsIDocument> with RefPtr.
We have ToSupports to handle this, so use it.
Differential Revision: https://phabricator.services.mozilla.com/D15350
This reverts the change implemented in bug 490178 in preparation for removing the inner scrollbox of the "richlistbox" binding.
--HG--
rename : toolkit/content/tests/chrome/test_richlist_direction.xul => toolkit/content/tests/chrome/test_richlistbox.xul
extra : rebase_source : 2a769cb8e47432574c47ba6565467c33ad3831bc
The only branch where it set differently is `try`/`try-comm-central`, but it gets
overriden there in `set_try_config`.
Differential Revision: https://phabricator.services.mozilla.com/D15478
--HG--
extra : moz-landing-system : lando
This event is used for shield-study which has finished, so we could remove it.
Differential Revision: https://phabricator.services.mozilla.com/D14810
--HG--
extra : moz-landing-system : lando
We've handle showing the blocking icon in patch2, so we don't need to set block permission in PermissionUI.
Differential Revision: https://phabricator.services.mozilla.com/D14797
--HG--
extra : moz-landing-system : lando
Use more proper name for actor which will handle all autoplay related events.
Differential Revision: https://phabricator.services.mozilla.com/D14796
--HG--
rename : toolkit/actors/AudibleAutoplayChild.jsm => toolkit/actors/AutoplayChild.jsm
extra : moz-landing-system : lando
This event is used to notify tab that this site is permanently blocked and we should show the blocking icon for it. Patch2 will handle following details.
Differential Revision: https://phabricator.services.mozilla.com/D14794
--HG--
extra : moz-landing-system : lando
With an event filter method, we're logging all key events on any widgets to
check whether a key is pressed or not, to set
WidgetKeyboardEvent::mIsRepeat properly. If iBus and Fcitx work as expected,
they synthesize key events with setting their own modifier state which indicate
the events are synthesized by IME. In this expected case, synthesized key
events are not caught by the filter.
On the other hand, in some environment, they keep handling key events
asynchronously but they or something another module synthesizes key events
without the flag and such events are caught by the filter because the events
are posted into the event queue. Therefore, we decide that such synthesized
events are always generated by auto-repeat (first events which are always
filtered by IME are treated as first press, and then, synthesized events are
treated as repeated events because of no key release events).
This patch makes KeymapWrapper::FilterEvents() ignore coming KeyPress
events if:
- the time is exactly same as previous KeyPress event
- and IMContextWrapper instance is now waiting a GDK_KEY_PRESS event
- and hardware_keycode of waiting GDK_KEY_PRESS event is same as
keyCode of the KeyPress event
Differential Revision: https://phabricator.services.mozilla.com/D15380
--HG--
extra : moz-landing-system : lando
This is to prevent Part 1 from breaking
testing/web-platform/tests/css/css-multicol/multicol-span-all-restyle-002.html
After introducing Part 1, we now use CreateContinuingFrame() to create
non-column-span wrapper frames, which use nsFrame::Init() rather than
InitAndRestoreFrame() to initialize them. Because the bits in
aState.mAdditionalStateBits are added to frames only when
nsCSSFrameConstructor::InitAndRestoreFrame() is called. We need a new
way to add the NS_FRAME_PART_OF_IBSPLIT to non-column-span wrapper
frames.
Note that we used to add NS_FRAME_PART_OF_IBSPLIT to both column-span
wrapper and non-column-span wrapper. After this patch, column-span
wrapper won't have NS_FRAME_PART_OF_IBSPLIT. That's fine because
column-span wrappers are not linked with other frames and they
shouldn't get this bit set.
Depends on D15134
Differential Revision: https://phabricator.services.mozilla.com/D15452
--HG--
extra : moz-landing-system : lando
In CreateColumnSpanSiblings(), aInitialBlock can be a DetailsFrame.
Therefore, when creating a non-column-span wrapper, we cannot assume
it's always a block frame. We need to use CreateContinuingFrame to
ensure the correct type of continuation is created.
Differential Revision: https://phabricator.services.mozilla.com/D15134
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Timothy Guan-tin Chien
Coroiu Cristina
Jonathan Kew
Daniel Varga
longsonr
Bogdan Tara
Michael Kaply
Tom Prince
alwu
Sylvestre Ledru
Vedant Nevetia
Vlad Baicu
Jan-Ivar Bruaroey
Rob Wood
Margareta Eliza Balazs
Masayuki Nakano
Cameron McCormack
Daniel Holbert
Ting-Yu Lin
quasicomputational
arthur.iakab