Currently, nsMenuBarListener::KeyPress() handles F10 key before remote content handles it. However, if a remote process has focus, the keyboard event should be handled in the content first. Then, only when it's not consumed in the remote process, menubar should handle the F10 key press.
MozReview-Commit-ID: GDf4POAPsTy
--HG--
extra : rebase_source : a450755d89bc410d17fef55fad98533169e2eff5
Currently, nsMenuBarListener::KeyPress() handles F10 key before remote content handles it. However, if a remote process has focus, the keyboard event should be handled in the content first. Then, only when it's not consumed in the remote process, menubar should handle the F10 key press.
MozReview-Commit-ID: GDf4POAPsTy
--HG--
extra : rebase_source : e016bc6dd7b5499458b6abc365f4879c1639f841
nsMenuBarListener::KeyPress() is eKeyEvent listener in the system event group. If the target is a remote process, it shouldn't handle accesskey immediately because preceding eKeyDown event may be consumed in the remote process or eKeyPress event itself may be consumed in the remote process.
This patch makes nsMenuBarListener::KeyPress() mark eKeyPress event as "waiting reply from remote process" only when the event matches with a menu item's accesskey and it will be send to a remote process later. Then, reply event should be handled in this method if it's available.
MozReview-Commit-ID: KOpCVgElnca
--HG--
extra : rebase_source : 881ec01f5c8e21c790bf9a8c3167d6c3f932524a
Currently, access key is handled in EventStateManager::PreHandleEvent() with eKeyPress event, i.e., before dispatching it into the DOM tree, if the access key is registered in EventStateManager. So, the main process does not check if the preceding eKeyDown event is consumed in focused remote process.
When preceding eKeyDown event is consumed in the main process, eKeyPress event won't be dispatched by widget. However, if remote process has focus, it's impossible widget to stop dispatching eKeyPress event because preceding eKeyDown event hasn't been handled in the focused remote process yet. Therefore, main process needs to post eKeyPress event to check if preceding eKeyDown event was consumed. When eKeyPress event is marked as "waiting reply from remote process", TabChild sends it back to the main process only when preceding eKeyDown event wasn't consumed. So, only when eKeyPress event is back to the main process, main process should handle accesskey with it.
This patch makes EventStateManager::PreHandleEvent() check if a remote target has focus before handling accesskey. If a remote process has accesskey and there is an accesskey matching with eKeyPress event, it marks the event as "waiting reply from remote content" and stop propagation in the process.
Finally, when eKeyPress event is sent back to TabParent, TabParent::RecvReplyKeyEvent() calls EventStateManager::HandleAccessKey() before dispatching the reply event into the DOM tree.
MozReview-Commit-ID: KsOkakaIVzb
--HG--
extra : rebase_source : 7e0c6966a1bde085e34d45bca4b0166b9fc2f3f1
In the frontend we need to know if XUL buttons in the toolbar were
triggered by a touch event, so we're passing on the inputSource
in the command event.
MozReview-Commit-ID: DMvgZULk9hT
--HG--
extra : rebase_source : c455c8ec77e439bf02c1e3e8d34a36e1fb5e3bd0
Most of the names passed to nsIStringBundle::{Get,Format}StringFromUTF8Name
have one of the two following forms:
- a 16-bit C string literal, which is then converted to an 8-bit string in
order for the lookup to occur;
- an 8-bit C string literal converted to a 16-bit string, which is then
converted back to an 8-bit string in order for the lookup to occur.
This patch introduces and uses alternative methods that can take an 8-bit C
string literal, which requires changing some signatures in other methods and
functions. It replaces all C++ uses of the old methods.
The patch also changes the existing {Get,Format}StringFromName() methods so
they take an AUTF8String argument for the name instead of a wstring, because
that's nicer for JS code.
Even though there is a method for C++ code and a different one for JS code,
|binaryname| is used so that the existing method names can be used for the
common case in both languages.
The change reduces the number of NS_ConvertUTF8toUTF16 and
NS_ConvertUTF16toUTF8 conversions while running Speedometer v2 from ~270,000 to
~160,000. (Most of these conversions involved the string
"deprecatedReferrerDirective" in nsCSPParser.cpp.)
--HG--
extra : rebase_source : 3bee57a501035f76a81230d95186f8c3f460ff8e
For resizing context menus when accessed through touch, it is useful
for frontend code to know the inputSource of the action that triggered
a menu during the popupshowing event.
MozReview-Commit-ID: DvPDHvPgoUN
--HG--
extra : rebase_source : 4f2cacf2e8b603bc206595a1f5e5c15b7ea04bd0
For resizing context menus when accessed through touch, it is useful
for frontend code to know the inputSource of the action that triggered
a menu during the popupshowing event.
MozReview-Commit-ID: DvPDHvPgoUN
--HG--
extra : rebase_source : e175a71377bb7d243aeb79325b649f57bc31e830
This patch decreases the assertion counts for toolkit/content/tests/chrome/test_bug437844.xul and layout/xul/test/test_bug393970.xul. It does so by preventing a loop in nsSprocketLayout.cpp from performing one extra pass after hitting the assertion. It also increases the maximum of the expected range for test_bug437844.xul to 34.
MozReview-Commit-ID: 3QVE2LY2sRa
--HG--
extra : rebase_source : de0c33067bb45770708c56b937fa2f4e6a6a3ce0
This is in response to an issue that's affecting the new app
update doorhangers on OSX, where the problem is more obvious.
On OSX, the panel styling makes it so that the doorhanger
overflows the window a little bit. This is fine until you enter
fullscreen with ctrl+command+F. At this point, the doorhanger
should come back onto the screen and the arrow should be rooted
to its anchor element (in our case the hamburger menu icon), but
instead it lags and the panel is not adjusted right away. This
is because right after the window is resized, which ends up
calling SetPopupPosition with aIsMove == false, SetPopupPosition
is called again from CheckForAnchorChange with aIsMove set to
true. There could be other solutions to this particular problem,
but since the aIsMove boolean is intended to limit the visual
noise when moving a window between screens, it seemed appropriate
for it to only prevent sliding or flipping if the panel isn't
already slid or flipped.
There was another issue affecting specifically the arrow, where
the logic for notifying observers of a positioning change in the
panel doesn't account for changes only to the position of the
anchor rect. This change adds tracking of that and sets aNotify
to true when called from ReflowFinished, since this is where
the position of the anchor element relative to the window can
need to change, even when the screen position of the panel rect
doesn't change.
MozReview-Commit-ID: Lpfokwkgl33
--HG--
extra : rebase_source : b05adc0b3f876196ff45499f0d70533f78cafb0e
Disable 461917-1.xhtml under dom/xul/crashtests/ because I cannot reproduce
it locally.
Annotate assert-if on some crashtests (bug 1370830). Other modifications are
all removal of fails-if.
MozReview-Commit-ID: 6Q2A5M5rOry
--HG--
extra : rebase_source : b282a919fcda6287fe2eaa6b139a11f2663ad578
nsIFrame::mClass is of type enum class nsQueryFrame::ClassID which is
a strict subset of the nsQueryFrame::FrameIID values. For a concrete
frame class, its FrameIID is the same numeric value as its ClassID.
MozReview-Commit-ID: 1N0AkCGo1ol
In bug 1359868 we started to do this, but we bounded the pre-render region for
the entire scrollbar by the widget bounds, which is not helpful for tall
scrollframes with short thumbs.
This time, we are bounding the pre-render region of the thumb only, so a small
thumb will always be completely painted.
MozReview-Commit-ID: 5LuP5Lfahdm
--HG--
extra : rebase_source : 3ab45f979160d7991aec71020cf57c9a1e57d1ce
Also add a comment to AsyncDragMetrics documenting that mScrollbarDragOffset
is relative to the thumb's start offset.
MozReview-Commit-ID: uipsOCzs2N
--HG--
extra : rebase_source : 25183e22cb7ffb9995a2594d6aea106cdef7924a
To conserve space in LayerAttributes, we only store the extents along the
relevant axis.
MozReview-Commit-ID: GAL8Oa2NOde
--HG--
extra : rebase_source : 9420d0fb36175e190cbff6e162fd41d8e5240c81
This flag is set to false if there are any conditions that only the main
thread knows about that prevent the thumb from being async-dragged.
MozReview-Commit-ID: Gl7f7bY0QnA
--HG--
extra : rebase_source : 60ab680a3995e3b5c0e1b4482ca0e7142352bbd2
The patch also renames Layer::SetScrollbarData() to Layer::SetScrollThumbData()
for clarity.
MozReview-Commit-ID: DVwJ3DMl3Zs
--HG--
extra : rebase_source : 7b2bfccf1351c82bb16296635e69d5488c87a50f
Transparency is not handled correctly for composited popups on any platform,
but works with varying degrees of success on some platforms, for some popups.
Oddly, out of the three main desktop platforms, Linux seems to handle it the
best, so long as we render the popup as opaque, and let the platform
compositor handle the transparency.
MozReview-Commit-ID: E8NQlToUQq3
--HG--
extra : rebase_source : c77da6eed1e95769798a14e873798df920fcb9b7
There are several behaviors that we only need to apply to popups which are
known to contain remote content. And since those behaviors can cause issues
elsewhere, we need to be able to identify popups which should contain remote
content, and treat them specially, where appropriate.
MozReview-Commit-ID: EMFrSP8lZiD
--HG--
extra : rebase_source : 5ee9da422081098d8099a048c7704008a06a7241
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
The APZ scrolling codepath doesn't do the right thing for <listbox>
without special handling, so have it scroll in JS instead, like we
did in bug 1302736 for <tree>.
MozReview-Commit-ID: LWJCBfhZ3Hc
--HG--
extra : rebase_source : bb8b2f7e713d35822a956e08f4e0eed0557b07b3
Supporting custom scrollbar mediators would require having custom logic in APZ
for each custom mediator. Since custom mediators are only used by legacy XUL
elements (<listbox> and <tree>) that isn't worth implementing.
MozReview-Commit-ID: KtCUvtiR1qn
--HG--
extra : rebase_source : dfd301da4d6877dd636c9719df46409db260d94c
The flush was added due to the overflow/underflow events causing recursion in some cases. But if the events aren't fired there is no point in doing this. The password manager test is changed to flush since it relies on showing/hiding tree columns but currently doesn't wait for a relayout before asking for cell information.
In the new architecture of Quantum DOM, all timer callback need a
specified event target. So, we add the new document arg to Start
function to get the event target from it. And update all callers.
MozReview-Commit-ID: a482mukqGc
--HG--
extra : rebase_source : 36f9d47a4afd7c7113adf3f274656b694b8d0943
In the new architecture of Quantum DOM, all runnables need a name label.
So, we add the new string-label arg to Start function, and update all
callers.
MozReview-Commit-ID: G9LXFjtFcQv
--HG--
extra : rebase_source : a19b605013be56d01780c831d2a48ada8825b1c7
This patch makes nsRepeatService stop inheriting from nsITimerCallback.
We needed that inheritance for InitWithCallback, but we do not need it
for InitWithFuncCallback.
This patch also makes nsRepeatService singly-owned instead of being
refcounted, since we're left with only a single owning pointer.
MozReview-Commit-ID: Fl8beVC8kGH
--HG--
extra : rebase_source : 3b6223c8e4754a90d2fef460940fda4510310f95
This was added in
https://hg.mozilla.org/mozilla-central/rev/9eabf947efc3363a1bf79aa03c3053d184510846
for https://bugzilla.mozilla.org/show_bug.cgi?id=957445#c29 but the
|aShouldRepaint| out parameter is not handled, and the call has no side
effects.
WidgetStateChanged() in nsNativeThemeWin and nsNativeThemeCocoa do not request
repaint of the scrollbar nor otherwise handle curpos.
nsNativeThemeGTK::WidgetStateChanged() requests a repaint on some changes in
curpos only on scrollbar buttons.
MozReview-Commit-ID: 98iyhLMs7ja
--HG--
extra : rebase_source : 512e0d9e825975a33fadd51e7c69d1ea0fa1cbef
Note that we still use InitWithCallback() instead of upgrading to
InitWithNamedFuncCallback(). This is because they have different lifetime
implications for the callback arg that nsMenuFrame passes in, mTimerMediator.
So to label the callback with InitWithCallback(), we make nsMenuTimerMediator
inherit from nsINamed to provide the label via that API's GetName method.
MozReview-Commit-ID: 45c6kDF2xCJ
--HG--
extra : rebase_source : 82a50ae01c6d23b7c495cc1ded68a27001631cff
This ensures that the pointer is always either null or a valid nsIContent after
the call to Rollup returns, and avoids potentially leaving it as garbage. An
alternative approach would be to make the call sites responsible for ensuring it
is set to nullptr if the function returns false, but this seems safer.
MozReview-Commit-ID: BXxPBgs6MZL
--HG--
extra : rebase_source : 89ab9984db5114595e581c98a049a0000ea19307
The relevant frame classes are:
SubDocumentFrame
ListControlFrame (only when used for (non-e10s?) comboboxes)
PluginFrame
ViewportFrame
MenuPopupFrame
The view is now created in the frame's Init() method, except for
ViewportFrame which has its view assigned by the frame constructor
via a SetView() call.
MozReview-Commit-ID: 4O7Hm1yqwIp
Views are used for PluginFrame which inherits nsFrame, not nsContainerFrame,
so it's more appropriate that these methods should live in nsIFrame/nsFrame.
MozReview-Commit-ID: 87EgCnkF5YT
This just decouples nsAutoRollup from the widget class, which it isn't really
bound to anyway because the internal data is static. We'll need to be able to
use nsAutoRollup independently in the next patch.
MozReview-Commit-ID: 1dxSLTr4g1K
--HG--
extra : rebase_source : 6f6964ca046b6f88e5c99c944a08b1c563f17837
This patch is written by the following script with some manual adjustment to
the comment in nsRubyTextContainerFrame.cpp and nsRubyFrame.cpp, and
nsColumnSetFrame's constructor.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "nsReflowStatus *([a-zA-Z0-9]*) = NS_FRAME_COMPLETE" "nsReflowStatus \1"
rename "([a-zA-Z0-9.*]*) *= NS_FRAME_COMPLETE;" "\1.Reset();"
rename "([a-zA-Z0-9.*]*) == NS_FRAME_COMPLETE" "\1.IsEmpty()"
MozReview-Commit-ID: 9tqQAHvdQex
--HG--
extra : rebase_source : 3119776946dc2c8350098b7bf9f3ceff29bdffb5
Weak frames are stored in a linked list, so are not fast. Hence they are not meant to be used when there can be a lot of them active at the same time. When constructing large selects with lots of options we create one for every option.
There's no need to use a weak frame for a reflow callback as we can just cancel the reflow callback in the Destroy function.
This is the bulk of the changes.
- DisplayItemScrollClip is removed. Instead, we will have 1) ActiveScrolledRoot
and 2) DisplayItemClipChain.
- ActiveScrolledRoot points to a scroll frame and allows traversing up the
scroll frame chain.
- DisplayItemClipChain is a linked list of clips, each clip being associated
with the ActiveScrolledRoot that moves this clip.
- Each display item has an ActiveScrolledRoot and a clip chain.
- nsDisplayItem::GetClip returns the item of the clip chain that scrolls with
the item's ASR. The separation between "regular clip" and "scroll clips"
mostly goes away.
- Tracking clips in the display list builder's clip state happens very
similarly to how regular clips used to be tracked - there's a clip chain for
content descendants and a clip chain for containing block descendants. These
clip chains are intersected to create the combined clip chain.
- There are strict rules for the ASR of a container item: A container item's
ASR should be the innermost ASR which the item has finite clipped bounds with
respect to.
- At some point in the future, ASRs and AGRs should be reunified, but I haven't
done that yet, because I needed to limit the scope of the change.
MozReview-Commit-ID: KYEpWY7qgf2
--HG--
extra : rebase_source : c727f6300a35463750639e165bfa37374c06b851
During the refactoring of nsSliderFrame::SetCurrentPositionInternal in Bug 957445, one
of the two calls to nsSliderFrame::UpdateAttribute was missed. This resulted in the position,
identified with nsGkAtoms::curpos, not being updated immediately after the call to
nsSliderFrame::SetCurrentThumbPosition
MozReview-Commit-ID: 6gedouG4OFX
--HG--
extra : rebase_source : dd29d90e6f10be87f652241ad138d4533bda1010
Delete the "or 0 for no movement in that direction" from the CanAdjustEdges
document in nsMenuPopupFrame.h because the only caller in nsResizerFrame.cpp
never passes 0 to it.
MozReview-Commit-ID: 3A5A8O4MDn1
--HG--
extra : rebase_source : 3a961f9195d7887f8abb5c31ae9ec088f78a2626
We aren't likely to implement predictive size decoding for XUL images. So instead do some sync decoding when we Draw them at their specified size. This will avoid a paint where we don't draw the image, or draw it at the wrong size, followed later by the correctly sized image.
Original patch by Tyler Maklebust <tmaklebust@gmail.com> and Jared Beach <beachjar@msu.edu>
MozReview-Commit-ID: 7FW6PHIrXF4
--HG--
extra : rebase_source : e8132fc8af91657ca80f18a841101bc1070c8b15
In cases where a mouse click that starts a scrollbar drag is also what
layerizes the scroll frame, the StartAsyncScrollbarDrag message needs to
arrive after the layer transaction. This patch ensures it does.
MozReview-Commit-ID: A02qRb6yWxg
--HG--
extra : rebase_source : 3517e8c8a578a0bd257a80bb8cb81303d171bb6c
This patch makes nsMenuBarListener clear its accesskey state when it receives a "deactivate" event of its top level window and reverts the change of nsMenuBarListener::Blur() by bug 625151.
"blur" event may be caused by focus move in the contents after "mosuedown" event. Therefore, mAccessKeyDownCanceled may be cleared unexpectedly. Listening to "deactive" event keeps bug 625151's fix because it's a bug after deactivating the window with Alt+Tab.
MozReview-Commit-ID: 4mAmXpxmDdv
--HG--
extra : rebase_source : 1bd9299a37bc5a1feccb61ba6c3db6b389560ec0
Let's move the code adding/removing event listers to nsMenuBarListener because it makes what we maintain them easier.
This patch makes nsMenuBarListener store event target which is composed document node of the menubar content as a weak reference but this must be safe because when nsMenuBarFrame (stored as mMenuBarFrame) is being destroyed, OnDestroyMenuBarFrame() which clears the storing event target reference is always called. We should be able to assume that the content and its composed document has never gone before destroying its frame...
MozReview-Commit-ID: DdOtRzUAL1Z
--HG--
extra : rebase_source : bfc337aaad447ad4a9d78b2f3a9e49c72db1498e
test_scroll_snapping_scrollbars.html is failing when apz.drag.enabled
is true because synthesizeMouse does not route events through APZ,
meaning that the drag is never handled by APZ or Gecko.
Resolve this by adding a check that mHandledByApz flag is true for
WidgetGUIEvent, and handle in Gecko if that is not the case.
MozReview-Commit-ID: IrxVLxqs64V
--HG--
extra : rebase_source : c76e9fed3dcab806b17e85740c94339ac0e7ccca
Matt Woodrow
Nicolas Silva
Sebastian Hengst
Masayuki Nakano
Emilio Cobos Álvarez
Wes Kocher
Sylvestre Ledru
Johann Hofmann
Andrew Osmond
Christoph Kerschbaumer
Nicholas Nethercote
Xidorn Quan
Ryan VanderMeulen
Carsten "Tomcat" Book
Bill McCloskey
Ethan Lin
Florian Quèze
Jonathan Watt
Greg Mierzwinski
Markus Stange
Cameron McCormack
Manish Goregaokar
Doug Thayer
Martin Stransky
Ting-Yu Lin
Peter Van der Beken
Botond Ballo
Alexis Beingessner
Geoff Brown
Jonathan Kew
Mats Palmgren
Shing Lyu
Marco Bonardo
Neil Deakin
Kris Maglione
Masatoshi Kimura
Daniel Holbert
KuoE0
Karl Tomlinson
Dan Banner
Ryan Hunt
Paul Bignier
Kartikaya Gupta
Boris Zbarsky
Iris Hsiao
Timothy Nikkel
Tom Tromey
Gijs Kruitbosch
Kearwood Gilbert
Phil Ringnalda
Ehsan Akhgari
Tyler Maklebust
Bobby Holley
Shing Lyu
cku
Olli Pettay
Kevin Wern