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
IGNORE BAD COMMIT MESSAGES because something landed and was backed out for no bug number
--HG--
extra : amend_source : 1134c379d1134fe160fd2d889488d07acd9f4177
Add LOCAL_GL prefix for all GL constant value.
Turn to use GL_RED and GL_RB if we use core profile.
Turn to use GL_RGB_422_APPLE instead of GL_YCBCR_422_APPLE for core profile.
MozReview-Commit-ID: FCwbrUEFUxI
PBrowser::RequestNativeKeyBindings() is used only when somebody tries to
execute native key bindings for synthesized keyboard events. Therefore, it
doesn't need to retrieve edit commands for all editor types. Instead, it
should take the editor type and just return the edit commands for it.
MozReview-Commit-ID: HF4Gz99SBQP
--HG--
extra : rebase_source : e332d2ef5ae36949a9a362d8f95c5d427c9812e7
Now, nsIWidget::ExecuteNativeKeyBinding() isn't used by anybody for executing
edit commands. Instead, they need array of edit commands for the key
combination. So, the method should be renamed to GetEditCommands() and just
return edit commands as an array.
MozReview-Commit-ID: 4G0B1lJ8Lbe
--HG--
extra : rebase_source : 4a5829281d59677c773950c34d91a1cd8074d243
Synthesized keyboard events in child process doesn't have edit commands when
it's being dispatched. With the old design, PuppetWidget needed to store all
edit commands for dispatching keyboard event but it's not necessary now because
WidgetKeyboardEvent will get only necessary edit commands when
WidgetKeyboardEvent::ExecuteEditCommands() is called.
So, PuppetWidget should stop calling TabChild::RequestNativeKeyBindings()
before dispatching keyboard events.
This patch changes browser_audioTabIcon.js which becomes permanent orange with
this change.
MozReview-Commit-ID: 1eK1mUahRMO
--HG--
extra : rebase_source : 13ce4aca8e45fa3d4b739a978bfa7dbddaf58ae3
When eKeyPress event is dispatched from TabParent to a remote process, it
should store edit command for all editor types. Then, copied
WidgetKeyboardEvent in the remote process doesn't need to request the edit
commands when its ExecuteEditCommands() is called.
Note that this patch also changes a automated test, browser_bug1316330.js,
that uses nsIDOMWindowUtils.dispatchDOMEventViaPresShell() to dispatch
repeated keyboard events in the tab. However, it should use synthesizeKey()
to emulate everything of native keyboard events and the API can dispatch
repeated keyboard events too. (And the test has a bug. It tries to wait 0.5
sec when every keydown or keypress event. However, it fails since startTime
is never initialized. This patch fixes this bug too.)
MozReview-Commit-ID: IYhyxqH3Ch8
--HG--
extra : rebase_source : 0db911e8e6ea7fc537bda76f4cc0f8952cc13dd2
Currently, edit commands for native key bindings are stored in widget. This is
stateful and really complicated in content process because it needs to cache
them.
We can make this simpler if we make WidgetKeyboardEvent store edit commands for
the key combination. Then, child process can handle it even if it's delayed
event or it's a nested event.
This patch adds arrays to WidgetKeyboardEvent to store edit commands which are
initialized with nsIWidget::ExecuteNativeKeyBinding() and adds
WidgetKeyboardEvent::ExecuteEditCommands() to execute stored edit commands as
same as nsIWidget::ExecutenativeKeyBinding().
MozReview-Commit-ID: BGRvBrLz5lp
--HG--
extra : rebase_source : b7ecd704d9c331ca1e0aedc66f230114015b853b
People seem to be turning on this pref in the wild and generating crash reports
which are wasting time and energy of people who have better things to do.
MozReview-Commit-ID: 5VfjKaDluYJ
--HG--
extra : rebase_source : fa2237835d842ddb118c6ba6096f6b703aef9d81
Remove the addPluginView and removePluginView methods from
GeckoInterface. Instead, move the JNI calls directly to GeckoApp itself.
GeckoApp then uses GeckoActivityMonitor to find the current activity,
instead of using GeckoAppShell.getGeckoInterface().
MozReview-Commit-ID: 7ym8kuElADV
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.
When dragging a `draggable=true` HTML DOM node, if no data is added to the
DataTransfer during the DragStart event, we currently cancel the drag. This is
inconsistent with Chrome's behaviour.
This patch adds a chrome-only (hidden from content) item to the DataTransfer:
application/x-moz-dummy-data. This data is added only when no other data has
been added to the DataTransfer, and the target of the dragstart event was a
draggable=true HTML DOM node.
This hidden node allows for the drag event to complete successfully, while
appearing the same as Chrome's behavior to content scripts.
MozReview-Commit-ID: HVqEr7aR6DD
This patch matches Chrome's behavior almost exactly, except it uses a slightly
different formula for the deltaY value that results in the same movement speed
as Chrome but doesn't drift over time.
Tested by confirming that trackpad pinch zoom now works on maps.google.com,
wego.here.com, and figma.com.
`beginGestureWithEvent` and `endGestureWithEvent` are not called for
applications that link against the macOS 10.11 or later SDK when we're running
on macOS 10.11 or later.
For compatibility with all supported macOS versions, we have to call
{begin,end}GestureWithEvent ourselves based on the event phase when we're using
the 10.11+ SDK.
See: https://developer.apple.com/reference/appkit/nsresponder/1526368-begingesturewithevent
GeckoAppShell.scheduleRestart was called from XPCOM toolkit when we
needed to restart after the Gecko thread exits. But because we made the
"Gecko:Exited" event contain a "restart" flag, we can handle that
entirely in Java now, so we don't need to call
GeckoAppShell.scheduleRestart anymore.
Prior to this patchset, we never hosted remote, scrollable content in widgets
other than toplevel and child windows, so all other widget types have APZ
disabled. Since we now need to host remote content in popup widgets, and would
like similar performance and behavior for those browsers as other remote
browsers, we also need to enable APZ for those widgets too.
MozReview-Commit-ID: AVDt9U5i2WK
When dragging a `draggable=true` HTML DOM node, if no data is added to the
DataTransfer during the DragStart event, we currently cancel the drag. This is
inconsistent with Chrome's behaviour.
This patch adds a chrome-only (hidden from content) item to the DataTransfer:
application/x-moz-dummy-data. This data is added only when no other data has
been added to the DataTransfer, and the target of the dragstart event was a
draggable=true HTML DOM node.
This hidden node allows for the drag event to complete successfully, while
appearing the same as Chrome's behavior to content scripts.
MozReview-Commit-ID: HVqEr7aR6DD
Add a static boolean sThreadDestroyed which can be accessed only on JAVA UI thread.
Set sThreadDestroyed to true at DestroyOnUiThread that will stop remain tasks to access the Bridge() instance at JAVA thread.
MozReview-Commit-ID: 5JtUFgc6Vl3
This part is mainly to mark the channel as urgent-start if src related
attributes in HTMLImageElement and HTMLInputElement is set and the channel is
open due to user interaction. Unfortunately, we cannot just check the event
state just after creating channel since some loading image tasks will be queue
and execute in stable state. Thus, I store the event state in elements and
pass it to the place where create the channel.
MozReview-Commit-ID: GBdAkPfVzsn
--HG--
extra : rebase_source : 715352317b4b600f8a7f78b7bc22b894bb272d27
APZCTreeManager::AdjustScrollForSurfaceShift is only called from the
compositor now, so there is no need to expose this API for callers in
widget code.
MozReview-Commit-ID: BySCQ8N4SuM
This works around a GTK bug that led to the default engine being used instead
for the first draw.
MozReview-Commit-ID: 4r48HNUgVBE
--HG--
extra : rebase_source : 83a964e02dba97cb0b52acde6b692d241c03ed57
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
Currently the profiler mostly uses an array of strings to represent which
features are available and in use. This patch changes the profiler core to use
a uint32_t bitfield, which is a much simpler and faster representation.
(nsProfiler and the profiler add-on still use the array of strings, alas.) The
new ProfilerFeature type defines the values in the bitfield.
One side-effect of this change is that profiler_feature_active() now can be
used to query all features. Previously it was just a subset.
Another side-effect is that profiler_get_available_features() no longer incorrectly
indicates support for Java and stack-walking when they aren't supported. (The
handling of task tracer support is unchanged, because the old code handled it
correctly.)
Prior to this patchset, we never hosted remote, scrollable content in widgets
other than toplevel and child windows, so all other widget types have APZ
disabled. Since we now need to host remote content in popup widgets, and would
like similar performance and behavior for those browsers as other remote
browsers, we also need to enable APZ for those widgets too.
MozReview-Commit-ID: AVDt9U5i2WK
--HG--
extra : rebase_source : a9482d966b9d910fe0f989f2ff5daf49d60033c8
extra : histedit_source : 4c039c182535acdc690abbc8201db749169e9b80
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
Because ProfilerMarkerPayload is the main type defined in these files, and
because the next patch is going to introduce ProfilerMarker.{h,cpp}, which
would be confusingly similar to the old names.
--HG--
rename : tools/profiler/core/ProfilerMarkers.cpp => tools/profiler/core/ProfilerMarkerPayload.cpp
rename : tools/profiler/public/ProfilerMarkers.h => tools/profiler/public/ProfilerMarkerPayload.h
extra : rebase_source : df22a2ab3867650348ae78fe959ff0366aff230b
Update the composition when setting/removing spans, so that we update
the selection/cursor during a composition. However, we must limit any
updating to the current composition only (as indicated by the
keep-current-composition flag), because the Facebook comment box behaves
incorrectly if we repeatedly start and end new compositions.
Due to bug 1358958, simply inserting a line breaker with composition events doesn't work as expected in HTML editor. Therefore, we need to dispatch "fake" Enter keypress event even if it's not handling Enter key actually or shouldn't dispatch keypress event anymore.
The method tries to dispatch Enter keypress event. If it's handling Enter key press actually and can dispatch keypress event normally, it dispatches Enter keypress event as-is. Otherwise, it tries to dispatch "fake" Enter keypress. It doesn't have Control, Option and Command key state for emulating to insert a line breaker. Additionally, its code value is not set to "Enter" because the fake key event isn't a physical key event.
If it cannot dispatch Enter keypress event, it dispatches composition events to insert "\n" even though it won't work in HTML editor.
MozReview-Commit-ID: 7AsJLKS8Tgz
--HG--
extra : rebase_source : 03a8628fd35eff404792691de0d2600f11ef1614
When typing Enter key when active keyboard layout is Korean IME and it has composition string, the composition string is committed and then, "insertNewline:" command is sent. However, TextInputHandler::DoCommandBySelector() consumes the command because the key event has already modified the composition string.
This patch makes TextInputHandler::DoCommandBySelector() consume the command if it's not handling keydown or neither dispatched keydown event nor dispatched keypress event (if it does) is consumed. Therefore, insertNewline:sender of nsChildView will be called later, then, it causes inserting a line break with a set of composition events.
MozReview-Commit-ID: Afr1FKZbUtL
--HG--
extra : rebase_source : 0c43986907553750b63bed0c95b3d5aaa1b16bea
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
--HG--
extra : rebase_source : 4b29b859aa5745fabe3db0fe68742328fc0af175
nsIFilePicker.displaySpecialDirectory is a string that can be set to TmpD,
Desk, or any other special directory value. The real value of this directory
will be read in the parent process.
Other browsers do not support any of these (IIRC), telemetry reports
essentially zero usage, and supporting them is contrary to the DOM spec.
Notes on specific events:
CommandEvent and SimpleGestureEvent: These are not supposed to be
web-exposed APIs, so I hid the interfaces from web content too
(necessary to avoid test_all_synthetic_events.html failures).
DataContainerEvent: This was a non-standard substitute for CustomEvent
that seemed to have only one user, so I removed it entirely and switched
the user (MozillaFileLogger.js) to CustomEvent.
ScrollAreaEvent: This is entirely non-standard, but we apparently expose
it deliberately to web content, so I didn't see any reason to remove it
from createEvent.
SimpleGestureEvent and XULCommandEvent: Can still be created from
createEvent(), but not by content.
TimeEvent: This is still in because it has no constructor, so there's no
other way to create it. Ideally we'd update the SMIL spec to add a
constructor. I did remove TimeEvents.
MozReview-Commit-ID: 7Yi2oCl9SM2
--HG--
extra : rebase_source : 199ab921acfc531b8b85e77f90fcd799b03c887b
1. add binding functions for -moz-border-*-colors support.
In Gecko, we use double pointers to nsBorderColors to store -moz-border-*-colors.
The computed values of -moz-border-*-colors are set by couple member functions.
To pass the computed value from Servo to Gecko, we need support for these member
functions as well. So, I'm adding some binding functions in this patch. The
actual use of these bindings to pass/store the computed values is separated
in the following patch, which should be a pure Servo change. See servo PR:
https://github.com/servo/servo/pull/16586.
2. update test expectations for -moz-border-*-colors support.
Note that with the support of -moz-border-*-colors, 165 mochitests and 17 reftests
could be fixed.
MozReview-Commit-ID: KDbp8C6Aoqd
--HG--
extra : rebase_source : 7d9675d9ece091ea6957dcae7d28c39066e69035
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
This is more consistent with moz_gtk_tabpanels_paint() and avoids
modifying the tab style context.
MozReview-Commit-ID: HpKSVrpvO9b
--HG--
extra : rebase_source : f4d4da5dc8419671c8c27586f7b370837311744b
This makes balancing with gtk_style_context_restore()/ReleaseStyleContext()
unnecessary, and the style resolution cached in the style contexts is not
invalidated so frequently.
MozReview-Commit-ID: BKwyqoQsjv2
--HG--
extra : rebase_source : 4733d66f8265007555cc17568033ece09e6cb2dc
Full Firefox on Linux can now be run with a --headless flag.
This includes seven parts:
1) Running all marionette tests in headless mode.
2) Prevents crashes where Firefox calls into GTK.
3) Adds a headless screen helper which supports changing the headless
screen size with the environment variables MOZ_HEADLESS_WIDTH and
MOZ_HEADLESS_HEIGHT.
4) Supports simulating moving a headless window.
5) Adds a stubbed out nsSound implementation.
6) Supports simulating size mode changes of headless windows.
7) Adds the --headless flag for Firefox.
We only ever need to enable APZ for popups which contain remote content. In
theory, enabling it for other popups shouldn't hurt, but having it enabled
adds overhead that we'd rather avoid, and causes painting issues under some
circumstances.
Ideally, the painting issues should be fixed, but disabling APZ is a good
short term workaround, and we should try to avoid the unnecessary overhead
either way.
MozReview-Commit-ID: AOivnTQBWQh
--HG--
extra : rebase_source : a1636aebdea84235e57922226c64fb987a4937a7
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
Add getChromeUri/setChromeUri APIs to GeckoView, to allow each
GeckoView's chrome URI to be set individually. This lets us remove
GeckoInterface.getDefaultChromeURI. This patch also changes the default
chrome URI to the GeckoView default, and let Fennec specify its chrome
URI (browser.xul) inside GeckoApp.
MozReview-Commit-ID: Gkwbp8VyLcu
Move checkUriVisited, markUriVisited, and setUriTitle from
GeckoApp/GeckoAppShell to GlobalHistory. Make them static and directly
accessible from native code, so that we can remove those methods from
GeckoInterface.
MozReview-Commit-ID: JrmlfeKibaW
Move shortcut creation code in GeckoApp to GeckoApplication, and make
the methods static so that we can call them without a GeckoInterface
instance. This lets us remove GeckoInterface.createShortcut.
MozReview-Commit-ID: AUnQGI02Bk
Move GeckoAppShell.launchOrBringToFront to GeckoApp, so that we can use
GeckoActivityMonitor to check whether BrowserApp is the current
foreground Activity. This lets us remove GeckoInterface.isForegrounded.
MozReview-Commit-ID: CgjnaNK8OGW
Invalidating a window's shadow is really slow and leads to flickering. Now that
arrow panels don't change their contents during the panel opening animation any
more, their shape stays the same after the first paint, so we don't need the
shadow invalidation functionality for them any more. And as far as I know, we
don't use transparent popups with changing shapes anywhere else.
The system still computes the shadow for the first paint of the window (which
happens during the orderFront call), and it updates the shadow whenever the
window resizes. But not when its size stays the same and only what we draw in
the content is updated.
MozReview-Commit-ID: 138PjbrSFrc
--HG--
extra : rebase_source : fed1c653ca3d88ef8b4e8e55a7d42b29e17a1624
IMEContentObserver notifies IME of 3 notifications at most when editor is changed.
The order is:
1. text change (with merged range if 2 or more change occurred during an edit transaction)
2. selection change (only the latest selection change. other changes occurred before that during an editor transaction are ignored)
3. position change (scrolled, resized, window moved, etc)
This does not check the behavior in designMode because some operation in testWithHTMLEditor() causes unexpected behavior, e.g., moving focus. It *might* be bug of design mode. However, it doesn't matter for this bug. The important thing of this bug is, there should be automated tests for IMEContentObserver. And fortunately, IMEContentObserver does not check the type of editor. So, it's enough to test only contenteditable element for HTMLEditor at least for now. Therefore, I gave up to test it in designMode for now.
MozReview-Commit-ID: 7L6ZlbVMU2P
--HG--
extra : rebase_source : 8282fe7aa2f4d405f2576f05d46b60b044223855
IMEContentObserver can store pointer of IMENotificationRequests of its mWidget. Therefore, it can check the requests dynamically when it receives content change or layout change.
This patch makes IMEContentObserver stores IMENotificationRequests as pointer and check it at every change notification received. Additionally, notification request may be changed due to focus move or something. Therefore, this patch makes IMEContentObserver and IMEContentObserver::IMENotificationSender() check if the notifications are still necessary.
MozReview-Commit-ID: 2uU2wN15D8v
--HG--
extra : rebase_source : 6086e0293343632df43087c767ad00521e764476
IMEContentObserver may need to change notifications to send when TextInputProcessor begins input transaction. In current design, IMEContentObserver needs to retrieve IMENotificationRequests at every change. However, if nsIWidget returns a reference to its IMENotificationRequests, IMEContentObserver can call it only once.
For that purpose, this patch changes nsIWidget::GetIMENotificationRequests() to nsIWidget::IMENotificationRequestsRef() and make it return |const IMENotificationRequests&|. However, if the lifetime of the instance of IMENotificationRequest is shorter than the widget instance's, it's dangerous. Therefore, it always returns TextEventDispatcher::mIMENotificationRequests. TextEventDispatcher's lifetime is longer than the widget. Therefore, this guarantees the lifetime.
On the other hand, widget needs to update TextEventDispatcher::mIMENotificationRequests before calls of nsIWidget::IMENotificationRequestsRef(). Therefore, this patch makes TextEventDispatcher update proper IMENotificationRequests when it gets focus or starts new input transaction and clear mIMENotificationRequests when it loses focus.
Note that TextEventDispatcher gets proper requests both from native text event dispatcher listener (typically, implemented by native IME handler class) and TextInputProcessor when TextInputProcessor has input transaction because even if TextInputProcessor overrides native IME, native IME still needs to know the content changes since they may get new input transaction after that.
However, there may not be native IME handler in content process. If it runs in Android, PuppetWidget may have native IME handler because widget directly handles IME in e10s mode for Android. Otherwise, native IME handler is in its parent process. So, if TextInputHandler has input transaction in content process, PuppetWidget needs to behave as native event handler. Therefore, this patch makes PuppetWidget inherit TextEventDispatcherListener and implements PuppetWidget::IMENotificationRequestsRef().
MozReview-Commit-ID: 2SW3moONTOX
--HG--
extra : rebase_source : d2634ada6c33dbf7a966fadb68608411ee24bfab
clang's -Wcomma warning warns about suspicious use of the comma operator such as between two statements.
widget/cocoa/nsDeviceContextSpecX.mm:246:26 [-Wcomma] possible misuse of comma operator here
widget/cocoa/nsDeviceContextSpecX.mm:247:32 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: GhZQgNemLAE
--HG--
extra : rebase_source : 0bcc8d425ba700eb6025ad92b2999c16e07a082b
extra : source : 753076ad649966f1a9fa0c0e8bd3213ece860d28
Our "chrome-document-loaded" observer may detect several different types
of widgets that can exist in the parent process, including the Android
nsWindow, PuppetWidget, etc. We should only set the global state to
ready when the first top-level nsWindow has loaded, and not just any
window.
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
On my machine, if I have my mouse cursor positioned flush against the right
edge of my screen (which is 1440x900@2x), locationInWindow has an x coordinate
of 1439.99609375. This value was rounded up to an integer screen coordinate of
2880, and for that coordinate we don't find a target APZC, and consequently
refuse to scroll.
MozReview-Commit-ID: CJic4g3Y6Ag
--HG--
extra : rebase_source : 6e2405e9370046b5359d3800c1d0f70c3059074e
The code in the OS X widget was calling ReceiveInputEvent on IAPZCTreeManager
with a ScrollWheelInput, which would bypass the multiplier code. This modifies
the widget to use a WidgetWheelEvent instead, so that it goes through the
IAPZCTreeManager multiplier handling for wheel inputs. Other platforms already
send wheel events in WidgetWheelEvent format so they don't have this problem.
MozReview-Commit-ID: 5gOOGnfD87W
--HG--
extra : rebase_source : f13c6e13a89ce450fa4f287eb30f054fe3fc326a
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
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
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
This version of the Dynamic Toolbar moves the animation of the toolbar
from the Android UI thread to the compositor thread. All animation for
showing and hiding the toolbar are done with the compositor and a static
snapshot of the real toolbar.
MozReview-Commit-ID: BCe8zpbkWQt
Allow to override Gtk+ theme for content process when e10s is enabled.
MozReview-Commit-ID: 1Kd2jLpBavA
--HG--
extra : rebase_source : b45171954ed9168e9d46511d53800044d91e5558
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
Supports creating a windowless browser on Linux without an X server. Most of the
changes are just adding branches to avoid calls in to GTK which calls
into X. Some of the bigger additions were adding a separate headless widget
which implements just enough to render a page. A headless look and
feel were also added since there are many calls into GTK in the platform
specific one.
Add two new prefs (widget.chrome.allow-gtk-dark-theme and widget.content.allow-gtk-dark-theme) to enable dark
themes in chrome and content when e10s is enabled.
When e10s is disabled then widget.chrome.allow-gtk-dark-theme controls both chrome and web content settings.
That may be a bit confusing but it's going to be here for two releases only (Firefox 57 is going to have e10s enabled by default) and actually matches recent state when only one ENV pref is used for both chrome and web content.
The existing MOZ_ALLOW_GTK_DARK_THEME environment variable is still considered, but, now is like widget.chrome.allow-gtk-dark-theme, no longer affecting separate content processes.
MozReview-Commit-ID: CCwriA66CNj
--HG--
extra : rebase_source : 93e9a504af3e7570f82ddaf0890e374fe939e919
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 looks like Google decided to split these jars out a bit, so we need to piece
them all back together.
We could probably just query the sdk version instead, but I'm not 100% sure
know when this setup changed - moreover we don't know when (if?) the paths
are likely to change again. SDK 26.0 still has lint 25.3.1, so the SDK and
lint versions don't appear to be tied.
It seems that only the lint* jars are needed to compile 'build/annotationProcessor',
however we need all the remaining jars in the classpath when running that code
in 'widget/android/bindings'.
MozReview-Commit-ID: GAKwMrVXW55
--HG--
extra : rebase_source : 4e790aaccae8ccc3f151c39bf1ef4404b2581d7a
There are scenarios where we have a TabParent in the UI process hooked up to
a PuppetWidget with a BasicLayerManager. Webextensions fall into this category.
In this scenario, the parent-side layer manager is not hooked up to
the compositor (that is, there is no entry in the CompositorBridge layer tree
state map for the layers id). However, the content-side still ends up creating
a ClientLayerManager or a WebRenderLayerManager, which expects the layers id to
be registered in the compositor. This results in brokenness (in the case of the
ClientLayerManager/PLayerTransaction) or crashes (in the case of WebRenderLayerManager/
PWebRenderBridge). Instead, this patch changes this scenario to have the content
process use a BasicLayerManager which seems safer.
MozReview-Commit-ID: 3f80aZrRrmD
--HG--
extra : rebase_source : 10ec78dd7daf1c1c889929f0d79e0b75675b4b05
GetScreenBounds() is slow for the GTK port so we override and use
mBounds directly in nsWindow::GetWidgetScreen()
MozReview-Commit-ID: ICElOCEzswf
--HG--
extra : rebase_source : 2fb450cc9d933346cebfdbff0b32ea4130550395
It is unnecessary to use Vista/7+ API via GetProcAddress
MozReview-Commit-ID: ELxCJev2jaZ
--HG--
extra : rebase_source : e1207ce5416d603090bd572ba745a703dadd93bf
I suspect that the PuppetWidget is trying to create the layer manager after
it has been connected to a TabChild but before the TabChild has populated the
CompositorOptions. This results in the PuppetWidget effectively getting an
uninitialized value for the CompositorOptions, and so it sometimes randomly
creates a WebRenderLayerManager, later resulting in a crash.
It seems like exposing the potentially-uninitialized CompositorOptions from
TabChild like this is a bad idea, so I'm removing that API and using the more
reliable gfxVars in PuppetWidget. This is fine for WebRender purposes because
we no longer care to allow having WR compositors co-exist with non-WR
compositors.
We may eventually want to remove the CompositorOptions entirely, but for now
the rest of the usage of it seems fine.
MozReview-Commit-ID: 6ekG8j1PskK
--HG--
extra : rebase_source : 0099e847ac356ca235969bcd81f47d65f49de2eb
ScreenHelperCocoa is the platform dependent part of the original
nsScreenManagerCocoa and nsScreenCocoa. It registers
NSApplicationDidChangeScreenParametersNotification and pushes updates
to ScreenManager. See patch part 4. for how ScreenManager works.
MozReview-Commit-ID: 1A5ha4Ys2dL
--HG--
rename : widget/cocoa/nsScreenManagerCocoa.h => widget/cocoa/ScreenHelperCocoa.h
rename : widget/cocoa/nsScreenManagerCocoa.mm => widget/cocoa/ScreenHelperCocoa.mm
extra : rebase_source : c7737e18656710c36f6c04ac71a17deeca3224a5
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
nsIScreen::GetId and nsIScreenManager::ScreenForId is removed in patch
part 6. These methods are still used by Fennec on Android to implement
Presentation API support so I changed them to concrete methods in
nsScreenAndroid and nsScreenManagerAndroid.
nsScreenAndroid and nsScreenManagerAndroid does not use the generic
Screen and ScreenManager class because its implementation is quite
different.
MozReview-Commit-ID: 4rxxIgvNxMb
--HG--
extra : rebase_source : 1f8a437f6a9465bd79ce9be37c9e3de6f6d7b2fd
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
ScreenHelperGTK is the platform dependent part of the original
nsScreenManagerGtk and nsScreenGtk. It registers monitors-changed
event listener from gtk and pushes updates to ScreenManager. See patch
part 4. for how ScreenManager works.
MozReview-Commit-ID: KBo7ZLFTjM3
--HG--
rename : widget/gtk/nsScreenManagerGtk.cpp => widget/gtk/ScreenHelperGTK.cpp
rename : widget/gtk/nsScreenManagerGtk.h => widget/gtk/ScreenHelperGTK.h
extra : rebase_source : 5607e31b62c928934cc45df7b2212428fbfd79c1
ScreenManager takes the common parts of ScreenManagerWin,
ScreenManagerGtk and ScreenManagerCocoa. It caches all screen
information in the new Screen class. The cache are updated when the OS
notifies there is a monitor config change; all changes will be pushed to
content processes via PContent (patch part 6.)
Screen is a pure data object. All platform dependent logic will be in
widget specific helper classes.
Each process will have a singleton ScreenManager object. Widget
specific helper object is held alive by the ScreenManager when
necessary, for example to receive updates from the OS.
The change to to VsyncDispatcher.cpp is due to unified-build bustage.
ScreenManager::ScreenForNativeWidget is not implemented because it
will be removed in patch part 6.
MozReview-Commit-ID: 5ezytAXSqHp
***
fixup
MozReview-Commit-ID: DQtq3UVZytA
--HG--
extra : rebase_source : c1a5aac713de783586e93109fe3e197ffdc1a3ca
It's only used by gonk. Remove it will make removing PScreenManager easier.
MozReview-Commit-ID: GCHonrz30xK
--HG--
extra : rebase_source : 73fbb4263b246d42cc38dd7a30edda9014953a97
It's not used anywhere in gecko or addons. Remove it will make
removing PScreenManager easier.
MozReview-Commit-ID: K3BHnktO7wU
--HG--
extra : rebase_source : 6f481759d1fb82d222ea6a92ebfd50dbb6cb63d5
It's not used anywhere. Remove it will make removing PScreenManager
easier.
MozReview-Commit-ID: 5dn8kDhTZVl
--HG--
extra : rebase_source : 96b8ddb18deee94ca256bfa118b60ceacfd2d677
For non-audible media, we shouldn't request audio focus because it might interrupt
other app who is playing music or podcast.
MozReview-Commit-ID: 25iWJktgKUw
--HG--
extra : rebase_source : ca96240967131d2d6cab00f7a39c0ef4e6f2df78
to follow the behavior of version 3.20 GtkRange's contents_gadget.
MozReview-Commit-ID: BQE6mQqsan8
--HG--
extra : rebase_source : ee0f35da45f3da2248f50ee925fb7f8e9b848636
in determining breadth of trough and scrollbar.
MozReview-Commit-ID: 3orNXdv6uZh
--HG--
extra : rebase_source : ad840ac199569da2e2fed7aa5e37ecc48a022fe2
This was used with GTK2, but is now unnecessary as discussed in bug 1278282.
moz_gtk_init() is now called from only one place and so will be called only
once.
MozReview-Commit-ID: 2KwJop6qsV9
--HG--
extra : rebase_source : 5649f34914f03f8285eeaad7937d1ecab853649d
Changes in behavior are intended to be minimal, but this adds distinct
metrics for horizontal and vertical scrollbars even with GTK versions < 3.20.
Updates on theme changes will be restored in a subsequent patch.
MozReview-Commit-ID: 4vi2nKxCxW7
--HG--
extra : rebase_source : 5e968126af00a7c1ff0a45d2ba3b46a0a20424be
There is no need to calculate thumb borders because thumb border-box sizes are
determined with GetMinimumWidgetSize, which includes GTK margin, border, and
padding, and the interior border width is irrelevant because thumbs have no
children.
MozReview-Commit-ID: K2N2RBJBRsB
--HG--
extra : rebase_source : c750cdf9c9722f7796c89b8083bf2bfd32fffcbb
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
UIEvent.isChar is not supported by the other browsers and the value isn't initialized any platforms except on macOS. So, the value isn't useful and we have no reason to keep it.
MozReview-Commit-ID: 4BLpo88gSZj
--HG--
extra : rebase_source : ca950f8cb618a0cadc99ba4c80b5a8df94a20f27
Bug 1344892 - 1. Add option to dispatch to priority queue; r=snorp
For the regular "gecko" option, change to dispatching to the XPCOM event
queue, and add a new "gecko_priority" option that dispatches calls to
the widget event queue. GeckoThread.waitOnGecko is changed to wait on
both the widget queue and the XPCOM queue. nsAppShell::SyncRunEvent is
changed to avoid a possible deadlock condition involving locking
sAppShellLock twice.
Bug 1344892 - 2. Update dispatchTo = "gecko" options; r=snorp
Update some existing dispatchTo = "gecko" options to "gecko_priority",
which typically involve UI events or JNI management calls like
disposeNative. As a rule, disposeNative is dispatched to the queue with
the least priority among the queues that other native members of the
same class dispatch to (i.e. "gecko_priority" if all other native
members dispatch to "gecko_priority", or "gecko" if any native members
dispatch to "gecko").
Bug 1344892 - 3. Update auto-generated bindings; r=me
profiler_get_profile() will return nullptr is the profiler is not active, so
there's no need to call profiler_is_active() just beforehand.
--HG--
extra : rebase_source : 9b7d4396599dc10230c5215492c9f63c48a4ff5e
According to ATOK's behavior, IME may send different line breaker from its platform's standard. Therefore, we should treat \r as \n too.
Additionally, currently, TextComposition doesn't allow to input \n with composition. However, this was added for preventing to see odd control characters as boxes with code point. Therefore, we should allow \n for IMEs. (It was allowed, this limitation is unexpected when I reviewed the patch to reject control characters in TextComposition.)
MozReview-Commit-ID: DzGSMgp89Av
--HG--
extra : rebase_source : 0644e5941a080583af8701546111fbf46ec646ec
Although, TextComposition's bug, those tests are not checked with expected values, we should fix them later.
MozReview-Commit-ID: 89jehNqMnCH
--HG--
extra : rebase_source : 2c622396edef067b92393f1e5e5291db9105417a
So, finally, Flush() should replace native line breakers in the composition string before dispatching composition events. However, if the composition string was set by Set(), i.e., it's already been replaced with native line breakers, we shouldn't try to do it again due to performance reason. Therefore, this patch adds |mReplacedNativeLineBreakers| to manage if it's already been called.
MozReview-Commit-ID: 5Y7ULWeP153
--HG--
extra : rebase_source : f825e45a7033c3c651e6324047e75c20f6c69b36
First of all, replacing native line breakers with XP line breakers needs to adjust offset and length of each TextRange. Therefore, we cannot just duplicate the code into TextEventDispatcher::PendingComposition::Flush().
For creating a new method to replace the native line breakers in PendingComposition::mString, we should separate range adjustment code to a static method, AdjustRange(), because we cannot use for loop simply because we need to adjust both mClauses and mCaret.
MozReview-Commit-ID: 5ycsN8EAs45
--HG--
extra : rebase_source : 0ef667669c9027958a0a955f4b883f70be89cbb3
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
Synthetic mouseevents generated from touch gestures are dispatched asynchronously
from the touch events. This means that the nsAutoRollup that the widget puts on
the stack during the dispatching of the touch events is no longer in scope when
we get around to firing the mouse events. As a result, the mouse events can end
up reopening rollups that got closed by the touch events and that shouldn't be
reopened. We fix this by stashing the rollup that was in scope while the touch
events were being dispatched, and make sure we keep that in scope for the
synthetic mouse events.
MozReview-Commit-ID: HjteKHfAqvD
--HG--
extra : rebase_source : 46217b1ba610ef193963ccab454a6f584af61a2b
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
Ryan VanderMeulen
Mats Palmgren
Carsten "Tomcat" Book
Masayuki Nakano
Wes Kocher
Kartikaya Gupta
JerryShih
Masatoshi Kimura
Jim Chen
Stephen A Pohl
James Willcox
Nathan Froyd
Nicolas Silva
Emilio Cobos Álvarez
Sebastian Hengst
Michael Layzell
Randall Barker
Jan Beich
Evan Wallace
Birunthan Mohanathas
David Anderson
Iris Hsiao
Kris Maglione
David Anderson
bechen
Tom Tung
Xidorn Quan
Lee Salzman
Cameron McCormack
Karl Tomlinson
vincentliu
Nicholas Nethercote
Ting-Yu Lin
Phil Ringnalda
Shing Lyu
Andrea Marchesini
Jeremy Chen
Aryeh Gregor
Kit Cambridge
Farmer Tseng
Farmer Tseng
Brendan Dahl
Markus Stange
Jim Mathies
Manish Goregaokar
Chris Peterson
Mike Hommey
Mike Conley
Joel Maher
Eugen Sawin
sotaro
Dylan Roeh
Milan Sreckovic
John Lin
Sotaro Ikeda
Cervantes Yu
Martin Stransky
Stone Shih
Tom Ritter
Oriol
Andrzej Hunt
Munro Mengjue Chiang
Kan-Ru Chen
Makoto Kato
Mason Chang
Alastor Wu
Bobby Holley
Olli Pettay
Boris Zbarsky
Bob Owen
Dan Banner
Florian Queze
Marco Bonardo
Jessica Jong