nscoord_MAX is (1<<30) so that we can check for overflow *after* adding
two nscoords. However, (nscoord_MAX + nscoord_MAX) will still overflow.
Subtracting one makes this no longer possible.
MozReview-Commit-ID: BtbQRMp5kWm
Because we want to remove nsAdoptingString. We have other variants that don't
use nsAdoptingString, which can be used instead. There are three basic
patterns.
1. The easiest case is when we don't check for success.
> nsAdoptingString s = Preferences::GetString("foo");
> foo(s);
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> foo(s);
2. The next case is when we check if the result is empty.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s.IsEmpty()) { ... }
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> if (s.IsEmpty()) { ... }
3. The final case is when we null check the result.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s) { ... }
becomes:
> nsAutoString s;
> nsresult rv = Preferences::GetString("foo", s);
> if (NS_SUCCEEDED(rv)) { ... }
The patch also avoids some UTF8/UTF16 conversions in a few places.
--HG--
extra : rebase_source : f339b1a3dda4dc93979d38c30c001fbe77485b55
nsMenuPopupFrame will constrain the size of its widget to its min and max size.
It will also request its nsView to resize to its frame rect. If its frame rect
is larger or smaller than the min or max size, nsView will be unable to change
the size of the widget, and each ViewManagerFlush will attempt a resize and
force a composite. When there are a lot of ViewManagerFlushes, this can
overload the compositor.
--HG--
extra : rebase_source : e32c3bb5445365ef76ea2a0700abb6911974afcc
extra : source : cadcf04ef23cee5ddbbbf216573c05d3fc0e53f2
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
Wes Kocher
Matt Woodrow
Nicholas Nethercote
Christoph Kerschbaumer
Carsten "Tomcat" Book
Sebastian Hengst
Manish Goregaokar
Ryan Hunt
Dão Gottwald
Bevis Tseng
Emilio Cobos Álvarez
Daniel Holbert
Masayuki Nakano
Sylvestre Ledru
Johann Hofmann
Andrew Osmond
Xidorn Quan
Ryan VanderMeulen
Bill McCloskey
Ethan Lin
Florian Quèze
Jonathan Watt
Greg Mierzwinski
Markus Stange
Cameron McCormack
Doug Thayer
Martin Stransky
Ting-Yu Lin