The machinery for suppressing the displayport during live resizes
was using the Observer service. However, in the case of multiple
browser windows, this meant that all the open browser windows would
have their displayport suppressed if *any* of the browser windows
was being resized. This was mostly ok, as the displayport suppression
would be turned off once the resize ended. However, the code to
kick off a repaint with the unsuppressed displayport would only get
triggered on one of the windows (whichever happened to process the
unsuppress message last).
This patch stops using the Observer service for the implementation
machinery, and instead locates the active TabParent of the relevant
nsWindow, and invokes the displayport suppression directly on that.
This fixes the repainting bug and also avoids unnecessarily
broadcasting the suppression/unsuppression notification to windows
that don't neccessarily need it.
MozReview-Commit-ID: LBHOgOW9KUp
When NativeKey crashes by itself, it means that we detect an impossible situation in usual environment. In such case, active 3rd party's keyboard layout or something other utility may hook API and returns odd result to us.
For investigating the cause and deciding what we should do in such cases, we should collect active keyboard layout name via crash reports.
MozReview-Commit-ID: HYRj24GwDHZ
--HG--
extra : rebase_source : 5f01c2a3b36179a61dc00eebd4de6f05596d217b
The machinery for suppressing the displayport during live resizes
was using the Observer service. However, in the case of multiple
browser windows, this meant that all the open browser windows would
have their displayport suppressed if *any* of the browser windows
was being resized. This was mostly ok, as the displayport suppression
would be turned off once the resize ended. However, the code to
kick off a repaint with the unsuppressed displayport would only get
triggered on one of the windows (whichever happened to process the
unsuppress message last).
This patch stops using the Observer service for the implementation
machinery, and instead locates the active TabParent of the relevant
nsWindow, and invokes the displayport suppression directly on that.
This fixes the repainting bug and also avoids unnecessarily
broadcasting the suppression/unsuppression notification to windows
that don't neccessarily need it.
MozReview-Commit-ID: LBHOgOW9KUp
--HG--
extra : rebase_source : 9e57054b22c58f5fcf815dfb3074a7201102fb4d
This patch makes sure content processes update their cleartype settings, as well as making sure Moz2D's idea of the ClearType settings are in sync with those of Thebes. If the two differ this can cause graphical glitches.
MozReview-Commit-ID: 94arUnBWoUy
--HG--
extra : rebase_source : d74b702fc63c019ce1c30bdc741ea3ed6da457cd
I did my best to remove as much stuff as possible in this patch. The starting
point was to remove all the IsVistaOrLater() and IsWin7OrLater() calls, but I
also grepped for various strings and found some other removable stuff that way.
I may have still missed some things.
Notable things done by this patch.
- It removes numerous blocklist entries.
- It removes CanComputeVirtualKeyCodeFromScanCode(), because it's always true
now.
- It removes ShowXP{Folder,File}Picker(), even though these were available as
fallbacks on Vista+. The "when platform is built without the longhorn SDK"
condition in the comment above nsFilePicker::ShowXPFolderPicker() sounds like
it won't ever happen any more.
- It removes the config.trim_on_minimize preference. This requires adding a
bool sHaveInitializedPrefs variable; previously the lack of pref
initialization was indicated by the tri-state sTrimOnMinimize variable having
the value 2.
Notable things *not* done by this patch.
- ClearThemeRegion() still exists. The comment suggests that it is XP/Vista
only, but the code suggests otherwise. jimm thinks the comment is wrong.
- The comment in WinWakeLockListener::Callback() suggests that the StartTimer()
call is no longer needed to block the screen saver. I'm uncertain about this
and so I think it's best left to a follow-up.
--HG--
extra : rebase_source : f46645907d237423fd6115ab1b4725b023a0dce3
This patch makes sure content processes update their cleartype settings, as well as making sure Moz2D's idea of the ClearType settings are in sync with those of Thebes. If the two differ this can cause graphical glitches.
MozReview-Commit-ID: 94arUnBWoUy
--HG--
extra : rebase_source : d74b702fc63c019ce1c30bdc741ea3ed6da457cd
This patch changes it from |NS_IMETHOD| to |virtual nsresult| because some
callsites are checked and some aren't.
--HG--
extra : rebase_source : dd98266bce0a7583863908b6f04729a6e403b721
This patch changes it from |NS_IMETHOD| to |virtual nsresult| because some call
sites are checked and others aren't.
--HG--
extra : rebase_source : 6723b9db709d1506dd394b1e85572309c1c2e2cf
This patch changes one from |NS_IMETHOD| to |virtual nsresult| and the other to
|virtual void|.
--HG--
extra : rebase_source : 55af71c01dc75d6bf7c63191e9cfabc9f5368ffa
This patch changes it from |NS_IMETHOD| to |virtual void|. The return value was
only checked in one low-value assertion and one other place where the check had
no useful effect (in nsCocoaWindow::HideWindowChrome()).
--HG--
extra : rebase_source : f6671e9e0e10ee18fb32f8b1c83f1e64c3d97e67
This patch changes it from |NS_IMETHOD| to |virtual void|. The return value was
only checked in one low-value assertion so I decided it wasn't needed.
--HG--
extra : rebase_source : 3523d9a086cf98c40d237d777f5dd471af0d7465
This patch adds a new non-DOM event type, "mousetouchdrag". The name is horrible, I
know. The "mouse" comes from the fact that it's a WidgetMouseEvent, and the
"touchdrag" comes from the fact that this event is fired at the start of a touch
gesture for drag-and-drop. Right now this event is only fired from the Windows
widget code, when we receive a touch-source doubleclick event from the OS. This
event is sent to us from the OS when it detects the sequence "touchstart, touchend,
touchstart" within certain time/distance constraints. Eventually we may detect
similar gestures for other platforms in the APZ GestureEventListener and dispatch
the "mousetouchdrag" event for those as well.
The only effect of this event is that it begins tracking a drag gesture in the
EventStateManager. Subsequent touchmove events can begin the actual drag-and-drop
operation by calling ::DoDragDrop. See the discussion in bug 1147335 for some
important caveats about DoDragDrop and how it only works with left-mouse-button
events (real or synthetic).
MozReview-Commit-ID: bGyOk6dRoJ
Add the set of plugin process PIDs to PluginProcessParent and, when attempting to reparent plugin windows in the chrome process, validate that those windows originated with the plugin process (by checking the window's PID against the set in the PluginProcessParent).
Kartikaya Gupta
Masayuki Nakano
Sebastian Hengst
Aaron Klotz
Benjamin Smedberg
Wes Kocher
Bill McCloskey
Bas Schouten
Nicholas Nethercote
Jean-Luc Bonnafoux
Ryan VanderMeulen
Markus Stange
Phil Ringnalda
Stone Shih
Xidorn Quan
Bob Owen
Jonathan Watt
Neil Deakin
Cervantes Yu
Carsten "Tomcat" Book
David Parks
Ting-Yu Chou