TSFTextStore::GetIMEOpenState() may be called a lot. Therefore, TSFTextStore should cache the compartment until shutting down.
MozReview-Commit-ID: 2jz8zQMBHRS
--HG--
extra : rebase_source : b322bcae129c73d7fdd1de080d525dbd6f34e6f8
sMessagePump is necessary only when WinUtils::(Get|Peek)Message() retrieves a message from the queue. Therefore, we can put off to initialize it until then.
MozReview-Commit-ID: ByMJk6AIw1r
--HG--
extra : rebase_source : e826fcd6e67b2b1599b31dda44140c1e7218da5a
sKeystrokeMgr is required only when WM_KEYDOWN or WM_KEYUP message are received. So, we can put off to initialize sKeystrokeMgr until then.
MozReview-Commit-ID: JsLeM0SYXG6
--HG--
extra : rebase_source : 766479689ec7739433b146fa5c0d7985fd6fc866
TIP name may be localed on some locales of Windows. Additionally, names may be updated in the future releases. So, it's safer to use GUID rather than name when TSFStaticSink checks active TIP is a specific one.
MozReview-Commit-ID: 6HNePZV7kgJ
--HG--
extra : rebase_source : 9d77c3124fc5ebeb82b9af1c13ae73633d9de4b8
Easy Changjei, a Traditional Chinese IME, isn't available on Firefox because:
* The vendor has gone and nobody keeps maintaining it.
* It crashes at first key press since it was built with older Visual Studio and depends on the version's CRT.
Therefore, we don't need to support it anymore.
MozReview-Commit-ID: LjyAvWsrlJ1
--HG--
extra : rebase_source : 481c4fdd5bbd6ed9984a101226f5232da9705430
Getting all prefs for TSFTextStore during initializing may make damage to start up performance.
So, each one should be retrieved when the one is actually necessary.
This patch creates TSFPrefs (I like better to name it TSFPreferences, but such long name isn't better when calling long name methods.) and implemented by simple macro.
MozReview-Commit-ID: A01LEAW4E7i
--HG--
extra : rebase_source : c471059c486c357eb270a7ea2ed1c5a07dd74e83
Although mChannelData uses infallible array, OOM occurs by AppendElements since clipboard data is too large. So we should use fallible array instead.
MozReview-Commit-ID: KdIWv2jGbDK
--HG--
extra : rebase_source : fe663b7f88d9d20bfb690fe0e17ec3652bd85231
Since committing will do IO on the main thread, it would be better to do it on
an idle thread instead. We have to change JavaScript code too because now the
API is asynchrous.
This patch also updates its xpcshell test.
Now mozilla::widget::AsyncDeleteAllFaviconsFromDisk will get profile directory
on the main thread to prevent it happens on off-main-threads, thus prevents
off-main-thread assertion.
MozReview-Commit-ID: CWcR0B2BC3n
--HG--
extra : rebase_source : 3685a07f9f4476bc94bdf92937734b78fb3fe309
I haven't really tested that this fixes the performance problem observed
in a profile without the patch because the steps to use the Gecko
Profiler on local builds on Windows are rather complicated.
MozReview-Commit-ID: FmGFs2Cvquv
--HG--
extra : transplant_source : %CB%AD%1E%2A%8F%DB%0D%9E%25%08%A82%13fP%BFS%82%BF%FC
The sandbox blocks loading of GMPs when the GMP resides in a directory stored
in a path which contains a symlink or junction point. So resolve GMP paths
fully before instantiating the GMP process.
MozReview-Commit-ID: EvPCpNIDNwg
--HG--
extra : rebase_source : 7df8236c9988a674ae128faf63b949fd711ab4e0
ITfProcessorProfiles are used by a debug method TSFTextStore::CurrentKeyboardLayoutHasIME() and TSFStaticSink (when it's initialized). However, TSFStaticSink isn't necessary until when TSFTextStore needs to hack something for specific IME or notifying IMEHandler of active TIP change. So, we can put off to create the instance of ITfInputProcessorProfiles and TSFStaticSink.
MozReview-Commit-ID: KcrqUbqz1do
--HG--
extra : rebase_source : f1821b782c6cd316a8f234a17ee3c92114547041
Creating them may be expensive due to allocating them in the heap. So, let's put off to create them when first use.
MozReview-Commit-ID: HDgijJo7brU
--HG--
extra : rebase_source : 9e4e68bd048185fe38fd98bef9b5711e86f68999
TIPs (and normal keyboard layouts) don't need IMC on focused window. So, in most environment, it's not necessary to restore default IMC of focused window.
Therefore, this patch makes IMEHandler not restore default IMC unless legacy IMM-IME is active and disassociate IMC from focused window when IMM-IME isn't active.
However, this is risky change. Therefore, the new behavior is disabled in default settings. On the other hand, we need the new behavior only when MS-IME for Japanese is active on Win10. Therefore, this patch adds a pref to enable/disable the hack and make it true in the default settings.
MozReview-Commit-ID: KAVxVT9CrsW
In TSF mode, application should retrieve messages with ITfMessagePump::GetMessage() or ITfMessagePump::PeekMessage() since TSF/TIP may handle the message before or after the host application handles it.
This patch rewrites the API users with WinUtils::(Get|Peek)Message() which use ITfMessagePump if it's available.
MozReview-Commit-ID: LwHIgp7SxLH
--HG--
extra : rebase_source : aa5750af9812f9b107c29546cbee6f9eede6ebfa
This patch does the following renamings, which increase consistency.
- GeckoProfilerInitRAII -> AutoProfilerInit
- GeckoProfilerThread{Sleep,Wake}RAII -> AutoProfilerThread{Sleep,Wake}
- GeckoProfilerTracingRAII -> AutoProfilerTracing
- AutoProfilerRegister -> AutoProfilerRegisterThread
- ProfilerStackFrameRAII -> AutoProfilerLabel
- nsJSUtils::mProfilerRAII -> nsJSUtils::mAutoProfilerLabel
Plus a few other minor ones (e.g. local variables).
The patch also add MOZ_GUARD_OBJECT macros to all the profiler RAII classes
that lack them, and does some minor whitespace reformatting.
--HG--
extra : rebase_source : 47e298fdd6f6b4af70e3357ec0b7b0580c0d0f50
This change changes PDFViaEMFPrintHelper so that instead of loading the entire
contents of a PDF document into memory to pass to PDFium, it now simply passes
PDFium a file system path to load the PDF from. This should help us reduce
memory use (and potentially avoid running out of memory) when larger PDFs are
printed.
MozReview-Commit-ID: GISolZYC2GJ
--HG--
extra : rebase_source : a59925542b6c075cd14c67577653163cc2d49c0f
While initializing or destroying TSFTextStore, each object methods should be
called after the instance is grabbed by local variable since member variable
may be cleared by nested call to destroy a TSFTextStore instance.
MozReview-Commit-ID: CojLasqcDyB
On Windows, when nsWindow is created, IMEHandler::InitInputContext() is called. Then, it calls TSFTextStore::SetInputContext(). However, at least for now, TSFTextStore needs to do nothing until the widget gets focus.
MozReview-Commit-ID: HBafHEUSCtd
--HG--
extra : rebase_source : 5c21e0f81dbc9b644965f7df42da1b6314b58a26
This function is arguably nicer than calling NS_ProcessNextEvent
manually, is slightly more efficient, and will enable better auditing
for NS_ProcessNextEvent when we do Quantum DOM scheduling changes.
This class helps draw a PDF file to a given Windows DC.
MozReview-Commit-ID: IjZAIcN3bND
--HG--
extra : rebase_source : 035dfbf5380316aacae8e1e1591d81971c47b843
This class exposes an interface to PDFium library and takes care of loading and
linking to the appropriate PDFium symbols.
MozReview-Commit-ID: 32jZD6d0KFw
--HG--
extra : rebase_source : 1d0580cbc8dc8687656ce32654d679da54104a33
WindowsEMF could be initialized with the path of a file where the EMF data
should be stored. If pass null point to the constructor that means the EMF data
are store in memory. Consumers can call GetDC() to get a HDC. It can be drawn to
generate the EMF output. After finishing with the HDC, call FinishDocument() to
finish writing the EMF output. Then consumers can call Playback() to play the
EMF's drawing commands onto the given DC. Once consumers don't use WindowsEMF
anymore, call ReleaseEMFHandle() to release object's handle. If the EMF output
is in memory, it is deleted. If it is on disk, it is not.
Consumers also can initialize WindowsEMF with an existing EMF file. They can
only use Playback().
MozReview-Commit-ID: 8hUsx8b2CXz
--HG--
extra : rebase_source : 99e38e61a00bfae45ec9102b3b23a095a7f3af1e
Because ModifierKeyState is in the 'mozilla::widget' namespace, this file uses
it without qualification.
MozReview-Commit-ID: H6t3AqLjRwJ
--HG--
extra : rebase_source : 69b788761ee332cc94acc4be6ae6ce0bb50f0e98
NS_SetCurrentThreadName() is added as an alternative to PR_SetCurrentThreadName()
inside libxul. The thread names are collected in the form of crash annotation to
be processed on socorro.
MozReview-Commit-ID: 4RpAWzTuvPs
We have to use the system scale here for consistency because GetThemePartSize and GetThemeMargins will always assume the system scale and callers of GetGutterSize will adjust the size using GetThemeDpiScaleFactor.
This patch will also fix an existing bug where native-themed elements are not scaled when layout.css.devPixelsPerPx has a non-default value on Windows 7.
MozReview-Commit-ID: ILHiOrkTPoT
--HG--
extra : rebase_source : 130dd313ed478d1fe8a9b88ce2705df985c817c3
Due to Windows doesn't support dnd in the pen message handler, we can't handle and consume WM_POINTER* to fire WidgetMouseEvent. On the other hand, we can't get some pen related attributes from Windows mouse messages. This patch gets and caches the attributes by handling WM_POINTER* but not fire WidgetMouseEvent to support dnd and pen related attributes. When handling the subsequent Windows mouse messages, we use the cached attributes to fire WidgetMouseEvent. Considering we might need to use WM_POINTER* someday, use a preference to control the behavior.
MozReview-Commit-ID: 5E60KO1zo0W
These defines cause include ordering issues that can result in build errors if
WinMessages.h is included before certain Windows headers.
To solve this issue this commit simply removes those defines since nowadays we
require Visua Studio 2015 to build and no longer need them.
MozReview-Commit-ID: GHMU05GUwHM
--HG--
extra : rebase_source : fcaadb93be6ff43f36ba98f164018d93c98a4e22
Needed because LogLevel is in the 'mozilla' namespace, but this file uses it
without qualification.
MozReview-Commit-ID: 5o2KV1GlcqM
--HG--
extra : rebase_source : 2b6bb2b6a6b0464b9c01c055101b23373d386c0f
We need the definition of CompositorWidgetDelegate in order to use
mCompositorWidgetDelegate.
MozReview-Commit-ID: Gr5G0SvCckk
--HG--
extra : rebase_source : 17db54c13bebb97c2d39e2dc0b69b7ad28346385
It is unnecessary to use Vista/7+ API via GetProcAddress
MozReview-Commit-ID: ELxCJev2jaZ
--HG--
extra : rebase_source : e1207ce5416d603090bd572ba745a703dadd93bf
ScreenHelperWin is the platform dependent part of the original
nsScreenManagerWin and nsScreenWin. It listens the WM_DISPLAYCHANGE
message and pushes updates to ScreenManager. See patch part 4. for how
ScreenManager works.
MozReview-Commit-ID: 20A3ZQKmH9a
--HG--
rename : widget/windows/nsScreenManagerWin.cpp => widget/windows/ScreenHelperWin.cpp
rename : widget/windows/nsScreenManagerWin.h => widget/windows/ScreenHelperWin.h
extra : rebase_source : a3058c237d38f72103251802ab5f5bbd672e9b70
This is the most important part of the patch series. It removes the
PScreenManager protocol and use ScreenManager directly in the content
processes.
Initial and subsequent updates are sent via PContent::RefreshScreens.
struct ScreenDetails are kept to serialize Screen over IPC.
nsIScreenManager::ScreenForNativeWidget is removed because
nsIWidget::GetWidgetScreen can replace it. nsIScreen::GetId is removed
because it's not useful for the more general Screen class.
MozReview-Commit-ID: 5dJO3isgBuQ
--HG--
extra : rebase_source : 06aa4e4fd56e2b2af1e7483aee7c0cc7f35bdb97
It's not used anywhere. Remove it will make removing PScreenManager
easier.
MozReview-Commit-ID: 5dn8kDhTZVl
--HG--
extra : rebase_source : 96b8ddb18deee94ca256bfa118b60ceacfd2d677
Updates consumers to the new behavior.
Some consumers are changed to use the "page-icon:" protocol, since it's not
trivial to join the icons table and get a single result out of it. In most cases
the join would return multiple results since a page can have multiple icon payloads.
These consumers for now will return the biggest payload, bug 1347532 will fix
some of them to properly pass a #size=NN fragment.
Note that, even before, these were just "moz-anno:favicon:" uris, and the
payload had to be fetched from the database.
Some other consumers for now just fallback to the largest payload, by passing 0
to GetFaviconURLForPage.
The favicon optimization still happens on the main-thread, bug 1346139 will
handle that problem.
Most of the changes involve handling the modified IconData objects, that now
retain an array of payloads, rather than just one. But note that .ico files are
not yet split into single frames, due to imagelib missing APIs that will be handled
in bug 1337402.
The other changes involve fixing queries to properly join with the new tables.
Finally, note that thanks to the FOREIGN KEYS support, removing from moz_icons or
moz_pages_w_icons will also remove relations from moz_icons_to_pages.
The system only supports square icons, so icons are resized based on their larger side.
This doesn't include new tests, those will be in a following changeset.
MozReview-Commit-ID: JUkpquhpS8y
--HG--
rename : toolkit/components/places/tests/unit/test_svg_favicon.js => toolkit/components/places/tests/favicons/test_svg_favicon.js
extra : rebase_source : fa49c4a81d6ab6b34a2f19ee4175e889a6e9d734
Some IME may handle WM_KEYDOWN message before application and may set the keycode value to VK_PROCSSKEY but not do actually. Similarly, IME may handle WM_KEYDOWN message and replace following WM_CHAR messages with different characters.
Therefore, even if WM_KEYDOWN message comes with VK_PROCESSKEY, NativeKey shouldn't stop dispatching keypress events if it detects following printable char messages.
MozReview-Commit-ID: DcC2qgcLDrQ
--HG--
extra : rebase_source : 85c6a5dd5700b4032d1a21ed28b25c313cefa5cd
Ctrl+Space causes WM_CHAR of ' '. On the other native applications, you can input ' ' with this key combination though, we shouldn't allow this because we need to remove Ctrl and Alt modifier state at dispatching keypress event for the limitation of TextEditor but this is important key combination for custom shortcut keys.
So, when Ctrl or Alt key is pressed but it doesn't change the inputting character, i.e., the character can be inputted without Ctrl or Alt, we shouldn't remove those modifier state from eKeyPress event.
MozReview-Commit-ID: 7omLvNdQWzW
--HG--
extra : rebase_source : 66d5015567799c489d925ac2419358913f808d63
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
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
In PresShell, eContextMenu event is marked as dispatched only in chrome when its shiftKey state is true. However, Shift+F10 causes the context menu, it should not be marked as so because this is standard shortcut key to open context menu on Windows.
This patch consumes Shift key state if previous key message is WM_SYSKEYDOWN of F10 before dispatching eContextMenu event. So, user cannot block to prevent its default at opening context menu with Shift+F10, we should discuss this later.
MozReview-Commit-ID: 1P9LpeJoQof
--HG--
extra : rebase_source : f77fcf6a4587bc131901d717325f6083b4a89393
Bug 1343075 - 1a. Add TextEventDispatcherListener::GetIMEUpdatePreference; r=masayuki
Add a GetIMEUpdatePreference method to TextEventDispatcherListener to
optionally control which IME notifications are received by NotifyIME.
This patch also makes nsBaseWidget forward its GetIMEUpdatePreference
call to the widget's native TextEventDispatcherListener.
Bug 1343075 - 1b. Implement GetIMEUpdatePreference for all TextEventDispatcherListener; r=masayuki
This patch implements GetIMEUpdatePreference for all
TextEventDispatcherListener implementations, by moving previous
implementations of nsIWidget::GetIMEUpdatePreference.
Bug 1343075 - 2. Allow setting a PuppetWidget's native TextEventDispatcherListener; r=masayuki
In PuppetWidget, add getter and setter for the widget's native
TextEventDispatcherListener. This allows overriding of PuppetWidget's
default IME handling. For example, on Android, the PuppetWidget's native
TextEventDispatcherListener will communicate directly with Java IME code
in the main process.
Bug 1343075 - 3. Add AIDL interface for main process; r=rbarker
Add AIDL definition and implementation for an interface for the main
process that child processes can access.
Bug 1343075 - 4. Set Gecko thread JNIEnv for child process; r=snorp
Add a JNIEnv* parameter to XRE_SetAndroidChildFds, which is used to set
the Gecko thread JNIEnv for child processes. XRE_SetAndroidChildFds is
the only Android-specific entry point for child processes, so I think
it's the most logical place to initialize JNI.
Bug 1343075 - 5. Support multiple remote GeckoEditableChild; r=esawin
Support remote GeckoEditableChild instances that are created in the
content processes and connect to the parent process GeckoEditableParent
through binders.
Support having multiple GeckoEditableChild instances in GeckoEditable by
keeping track of which child is currently focused, and only allow
calls to/from the focused child by using access tokens.
Bug 1343075 - 6. Add method to get GeckoEditableParent instance; r=esawin
Add IProcessManager.getEditableParent, which a content process can call
to get the GeckoEditableParent instance that corresponds to a given
content process tab, from the main process.
Bug 1343075 - 7. Support GeckoEditableSupport in content processes; r=esawin
Support creating and running GeckoEditableSupport attached to a
PuppetWidget in content processes.
Because we don't know PuppetWidget's lifetime as well as nsWindow's,
when attached to PuppetWidget, we need to attach/detach our native
object on focus/blur, respectively.
Bug 1343075 - 8. Connect GeckoEditableSupport on PuppetWidget creation; r=esawin
Listen to the "tab-child-created" notification and attach our content
process GeckoEditableSupport to the new PuppetWidget.
Bug 1343075 - 9. Update auto-generated bindings; r=me
I've moved the body of the APIs into the few remaining callers.
MozReview-Commit-ID: 9ALoSmQHkGM
--HG--
extra : rebase_source : e0e747dec23424446b18d53ab65e4fa262e16554
According to crash reports, we may find WM_CHAR whose wParam is 0 and scancode is 0xFF with a call of PeekMessage(PM_NOREMOVE) but we'll remove usual char message with a call of PeekMessage(PM_REMOVE).
In such case, we should ignore the found odd message and take the usual char message which was removed from the queue actually.
MozReview-Commit-ID: Gw8LvCXxul
--HG--
extra : rebase_source : 51d4879c4ee0d89152de7986b81af08d03b9c244
When user input is used to dismiss popups, the user input may sometimes
be consumed (for example, clicking on a combobox element will dismiss
the combobox popup, but consume the event to avoid reopening the popup
right away). This handling was present for some types of input events but
missing for touch events. This patch adds it for touch events as well.
MozReview-Commit-ID: 5wsuTdMbkX2
--HG--
extra : rebase_source : 88518f699586224a6f4755553053503f54249c9b
The new names make it clearer that these actions apply to just one thread.
- profiler_sleep_start() --> profiler_thread_sleep()
- profiler_sleep_end() --> profiler_thread_wake()
- profiler_is_sleeping() --> profiler_thread_is_sleeping()
- GeckoProfilerSleepRAII --> GeckoProfilerThreadSleepRAII
- GeckoProfilerWakeRAII --> GeckoProfilerThreadWakeRAII
Currently, we use alias NS_VK_* for WidgetKeyboardEvent::mKeyCode. Similarly, we should create alias enum for nsIDOMKeyEvent::DOM_KEY_LOCATION_*. Then, we can reduce the length and avoid to include nsIDOMKeyEvent in some cpp files.
MozReview-Commit-ID: 5cs4zQ061Lc
--HG--
extra : rebase_source : e6a6edd27718b9e3d4a40b07902d029791876999
There are still a lot of crash due to failing to get following WM_CHAR message. Almost half of them are, we found a WM_CHAR message but it's gone at removing the message from the queue.
Although, we're still not sure what happen actually. It could be possible if somebody hooks PeekMessage() or something. Then, we can assume that the found message isn't necessary for the user because it must be removed by somebody when it became unnecessary or is handled.
This patch mark a new bool flag, mCharMessageHasGone, as true in such case. Then, NativeKey will dispatch keypress events without following char messages and mark the event as consumed.
MozReview-Commit-ID: mporX1sihC
--HG--
extra : rebase_source : a1badc205a99efd803de624d24b69e911f81d308
NativeKey::GetFollowingCharMessage() may remove a char message which is different from previously found message in the queue because hacky keyboard layout or utility can overwrite the wParam when it's removed from the queue.
Now, we should assume that newer message, i.e., actually removed from the queue, is the expected message by the user. See bug 1336028 comment 0 for the actual scenarios which are collected by crash reports.
https://bugzilla.mozilla.org/show_bug.cgi?id=1336028#c0
MozReview-Commit-ID: 9ZgukHH1vfi
--HG--
extra : rebase_source : 15559e62882f97d5062703e2308fa1c22016f340
Currently, NativeKey::GetFollowingCharMessage() tries 5 times to remove found char message from the queue. It was enough when we found this issue at developing Metrofox.
However, this hack is not enough for some odd keyboard layouts because we see some crash reports which gives up to remove a char message from the queue because 5 WM_NULL messages are returned.
For preventing this crash, we should check if there is the message which is trying to remove from the queue when NativeKey receives WM_NULL. Then, when there is no key message in the queue or next key message becomes non-char message,, NativeKey should dispatch consumed keydown event because we can assume that the key operation may have already been handled or canceled. Otherwise, NativeKey should retry to remove the message again (until 50 times!, it's just enough big magic number, there is no concrete reason).
MozReview-Commit-ID: 1c6Y4OoQdrP
--HG--
extra : rebase_source : 2ad588d0513741ff6a58be6f523cf59d8deea151
I think that when PeekMessage(PM_REMOVE) failed to remove a char message but next key message is still a char message, it may be possible that the odd keyboard layout or utility hook only PeekMessage(PM_NOREMOVE) and GetMessage(). If so, we can explain what occurs in this case.
I'm still not sure this fixes the case of bug 1336322 comment 0, but we should try to do this because I don't have better idea.
MozReview-Commit-ID: CxoO24n167t
--HG--
extra : rebase_source : c00b86166a345eec18fa2de74698f6e8859364b8
This patch depends on bug 1336080.
When PeekMessage() fails to remove found char message, NativeKey::GetFollowingCharMessage() tries to check next key message in the queue again. Then, when next key message becomes non-char message, such as WM_KEYDOWN or WM_KEYUP, the char message must be removed by odd keyboard layout or something. Similarly, when next key message is a char message but it's caused by different key, the found char message must be removed by one of them too.
So, in these cases, NativeKey::GetFollowingCharMessage() should treat the key operation is already handled or canceled by the odd keyboard layout or somebody else. Additionally, in the latter case, following char message should be handled as orphan char message(s) as usual.
MozReview-Commit-ID: 8ahs8I0HUQ2
--HG--
extra : rebase_source : 563efc0e65c1d400a32cb0ceec94eb56ad0aa1c5
When NativeKey::GetFollowingCharMessage() tries to remove a char message from the queue, the message might be changed by odd keyboard layout or something. In such case, if the new char message is also caused by same physical key, the char message must be overwritten. Then, we should take the new char message instead.
Note that this patch saves original found char message into kFoundCharMsg and it's logged by each points for indicating if this case has occurred.
MozReview-Commit-ID: HAduq8sfwFt
--HG--
extra : rebase_source : c8980c7fa019fc3e0f249b4506fa572e81f4a1e8
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
As of bug 1325299, WINVER is always >= 0x0601 (Windows 7).
MozReview-Commit-ID: Hw5FcEdP0os
--HG--
extra : source : 239400b39f806592a621473ac3a6dd79b238e725
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 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
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
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
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
This patch changes it from |NS_IMETHOD| to |virtual void| because every
implementation of these functions always returns |NS_OK|.
--HG--
extra : rebase_source : 07ee29c514bf35b97d7195c53bb5b9220d1ef961
This patch changes them from |NS_IMETHOD| to |virtual void| because every
implementation of these functions always returns |NS_OK|.
--HG--
extra : rebase_source : 6207df5a46aeb6b8aaa0f697447a51bc6a6dc366
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from the android nsIWidget instance,
because it can use the nsBaseWidget one.
--HG--
extra : rebase_source : 0791d3cb05907d6b41879549b52f3a33018abf45
This patch removes its return value, because none of the call sites check it
except for one non-vital assertion.
--HG--
extra : rebase_source : 3471c4e22394b8a05c6708d0f8469686ffad9814
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : a1a04193bc3940f1468c7c235f6d6e0341d0f1c2
Specifically: OnDefaultButtonLoaded, AttachNativeKeyEvent, BeginMoveDrag,
BeginResizeDrag, GetAttention. These are all fallible functions whose result is
always checked.
The patch also moves some trivial function definitions from nsBaseWidget.cpp to
nsBaseWidget.h, and removes the android BeginResizeDrag() because it can
use the nsBaseWidget one.
--HG--
extra : rebase_source : ef32a41b547bcbc21f7df0043f683307470b136e
When mWidget was already destroyed, anybody shouldn't dispatch WidgetEvent on it. Therefore, NativeKey::InitKeyEvent() has MOZ_CRASH() for detecting such dangerous bug and some users hit it.
Each message handler of NativeKey should check if mWidget has already gone.
Ideally, nsWindow shouldn't create NativeKey and try to handle the message with it. However, using NativeKey's message handlers can put some information to the log. Therefore, this patch doesn't touch nsWindow.
MozReview-Commit-ID: 4k5VfaKHPgG
--HG--
extra : rebase_source : 4269847fbdf5daa66244ce924ddc54feb5c6cd01
This completes the migration of code from the github branch to the graphics
project repo. At this point all webrender-related code should be disabled
unless --enable-webrender is provided in the mozconfig.
MozReview-Commit-ID: Dea8rxM6UPL
After click events with button 2 or 3 are fired, fire auxclick, a new
event intended to represent a non-primary mouse click. Because this
event, based on the design examples and blink's implementation, is
intended to be used with content listeners, always dispatch on content
listeners--not just those that force all events to be dispatched (i.e.
document/window). This diverges from the behavior of our click events
from non-primary buttons.
Eventually, we hope this will replace click events for non-primary
buttons. For now, leave those events for compatibility reasons.
Additionally, add handling of this new event, where necessary.
MozReview-Commit-ID: 8osozM4h6Ya
--HG--
extra : rebase_source : 558261dd0d0b9241efa84ca168c50455850af03a
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
Tom Ritter
Carsten "Tomcat" Book
Masayuki Nakano
Eric Rahm
Alexis Beingessner
Makoto Kato
sotaro
Wei-Cheng Pan
L. David Baron
Chris Pearce
Nicholas Nethercote
Sebastian Hengst
Karl Tomlinson
Kris Maglione
Ryan VanderMeulen
Farmer Tseng
Mats Palmgren
Nathan Froyd
David Anderson
David Anderson
Emilio Cobos Álvarez
Farmer Tseng
Jim Mathies
Manish Goregaokar
Cervantes Yu
Mike Conley
Masatoshi Kimura
Joel Maher
Wes Kocher
Kartikaya Gupta
Milan Sreckovic
Stone Shih
Oriol
Kan-Ru Chen
Marco Bonardo
Gaith
Boris Zbarsky
Bob Owen
David Major
Iris Hsiao
Jim Chen
Michael Layzell
David Parks
Tom Tromey
Aaron Klotz
Chris Peterson
Daniel Holbert
Emanuel Hoogeveen
Ryan Hunt
Tracy Walker
Benjamin Smedberg
Bill McCloskey
Phil Ringnalda
Jonathan Watt
Bas Schouten
Neil Deakin
Jean-Luc Bonnafoux
Jonathan Kew
Ting-Yu Chou
Morris Tseng
Markus Stange
Xidorn Quan
Mozilla Graphics Team
Andrew McCreight
Kevin Wern