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
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
It appears that neither Chrome, Safari or Edge support this feature,
and it's causing web-compat issues for us, e.g. bug 1373417.
MozReview-Commit-ID: AP5LMgL6QmR
Extending it didn't play well with invalidation; widgets would only be able to
draw outside if the invalidated region of the current paint was larger than the
widget's declared paint rect but not if the widget was the only thing that got
invalidated.
Any legitimate widget overflow should instead be handled by GetWidgetOverflow.
The DrawCellWithSnapping overflow is considered to stay within the focus
ring's bounds.
I fuzzed two reftests which have extremely slight variance when -moz-appearance
is combined with box-shadow. I don't really understand this failure but I don't
think it's worth looking into either.
MozReview-Commit-ID: ECYxnCTafdh
--HG--
extra : rebase_source : 2cf9b21812347d18cd98cf3f1570b80074551d94
This fixes HiDPI and adds overflow for meter bars.
Meter bars should probably have their intrinsic size fixed instead, but
keeping the existing behavior for them is less risky.
MozReview-Commit-ID: xF83bqdDlz
--HG--
extra : rebase_source : d28b4c265298e870d7cc03b11038da605d920b49
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
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
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
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
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
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
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
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
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
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
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
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 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
Because of conforming to UI Events KeyboardEvent key Values, when some modifier keys cause not inputting character, the KeyboardEvent.key value should be computed with removing all modifier state except glyph modifier keys.
When Control key is pressed, Cocoa fires odd key events typically. For example, characters isn't computed with same logic of UI Events KeyboardEvent key Values especially when Option key is pressed (see adding testcases for the detail).
Therefore, this patch makes TISInputSourceWrapper::InitKeyEvent() ignore both characters and charactersIgnoringModifiers at computing KeyboardEvent.key value when Control key is pressed and InsertText() isn't called.
On the other hand, this patch does NOT touch the path to compute KeyboardEvent.key when Command key is pressed. It should be changed in different bug because Command key behavior isn't so simple.
MozReview-Commit-ID: dMHgUEOnQw
--HG--
extra : rebase_source : 7a67c98d2bf6ca38c7e6ae9dcbad01020d9cea31
macOS oddly sends kVK_ISO_Section instead of kVK_ANSI_Grave when user types left key of Key1 only when the connected keyboard is ISO keyboard. On the other hand, macOS sends kVK_ANSI_Grave instead of kVK_ISO_Section when user types left key of KeyZ only when the connected keyboard is ISO keyboard. So, macOS swapps their key code values only when ISO keyboard is connected.
So, we should treat them as swapped when we compute KeyboardEvent.code value since Chromium treates them as swapped only when computing KeyboardEvent.code value too.
MozReview-Commit-ID: BYeFedydyR5
--HG--
extra : rebase_source : c3bf2a9fefe0e3e98a1955e829243f8fd7d1041a
Korean IME and some other simple IME may not use marked text at composing text. Such IME modifies composing character with InsertText() with aReplacementRange. Then, when
user types new character, such IME may replace the previous character with a call of InsertText() with aReplacementRange and insert the next character with additional call of InsertText() without aReplacementRange.
In this case, InsertText() ignores the call when the native keydown event is already caused composition events. However, we need to allow to dispatch keypress event for supporting to insert text even in such case.
This patch checks if inserting text is printable. If it's not a printable character such as U+000A at pressing Enter, keeping current behavior. Otherwise, dispatching keypress event instead.
MozReview-Commit-ID: 5NcCgXfvniO
--HG--
extra : rebase_source : f05db8655d623880cb658cef144d1e9fcdce8a2a
For a table, the primary frame is the table wrapper anonymous box. That
anonymous box inherits style from its _child_ table frame, which is the frame that
has the actual style for the element. So we want to use the stylo-computed
style for the table frame, and then compute an updated style for the table
wrapper too, because some things (like absolute positioning) are done for the
table wrapper anonymous box, not the table frame.
From https://developer.apple.com/reference/objectivec/1418956-nsobject/1418583-respondstoselector :
> You cannot test whether an object inherits a method from its superclass by
> sending respondsToSelector: to the object using the super keyword. This method
> will still be testing the object as a whole, not just the superclass’s
> implementation. Therefore, sending respondsToSelector: to super is equivalent
> to sending it to self. Instead, you must invoke the NSObject class method
> instancesRespondToSelector: directly on the object’s superclass.
MozReview-Commit-ID: 8wTexCQWUPw
--HG--
extra : rebase_source : f392bfe75c0a5c270b12b0f4ea2abdc6f737d5c2
Bug 1180564 dropped NSTextInput protocl implementation from ChildView but IMEInputHandler::SendCommittedText() still calls it via mView. Therefore, it fails to commit composition in widget level. Instead, we it should call insertText:replacementRange: of NSTextInputClient protocol.
Additionally, this patch adds a last resort path. If calling insertText:replacementRange: didn't commit composition in widget level, it calls TextInputHandler::InsertText() directly.
MozReview-Commit-ID: BZZypBqC0Mx
--HG--
extra : rebase_source : bef5612a933db3211400e9d8bd2848690de2d2e5
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
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
This patch implements nsCocoaUtils::GetEventTimeStamp() which hides how to get TimeStamp from timeStamp of NSEvent from other developers.
Different from Windows and GTK, we don't need to use SystemTimeConverter and implement CurrentTimeGetter class because the internal value of the macOS implementation of TimeStamp is based on mach_absolute_time(), which measures "ticks" since boot. Event timestamps are NSTimeIntervals (seconds) since boot. So the two time representations already have the same base; we only need to convert seconds into ticks.
MozReview-Commit-ID: LvioyJOM7S9
--HG--
extra : rebase_source : 0e497f675f9b7e1355155dc081945478f83019a8
This patch converts some NS_IMETHOD and NS_IMETHODIMP occurrences that I missed
in previous bugs.
The patch also removes the Android
nsWindow::{Get,Set}HasTransparentBackground() functions because they're unused.
--HG--
extra : rebase_source : 7b121e5f9ac633ea9482bacc8b7424cb8d8889ef
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 changes it from |NS_IMETHOD| to |virtual nsresult|. The callsites
were a mix of checked and unchecked so using |MOZ_MUST_USE| didn't feel
appropriate.
--HG--
extra : rebase_source : 471ca43dcd565ddd1761d01df344c30e4e04a9ec
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
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
Each concrete class of imgIContainer is able to handle opacity already. All we
need to do is pass opacity value to them.
MozReview-Commit-ID: EMkLnG3YXA1
--HG--
extra : rebase_source : b0a0aad1fec0c2765e96d23ed9b627345c793795
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
Currently, when InsertText() which is caused by a key press causes committing composition, it consumes keypress event. However, Korean 2-set IME calls InsertText() two times when there is composition and key press causes inserting another character next to the composition. In this case, current design ignores second InsertText() becuase keypress event is already consumed by the first InsertText() call.
For solving this issue safely, InsertText() should mark current key event as "dispatched composition event". Then, following InsertText() calls should cause composition events instead of keypress events since following event order is too odd:
1. keydown (currently not dispatched by TextEventDisaptcher)
2. compositionupdate
3. compositionend
4. keypress
5. keyup
with the new design this becomes:
1. keydown (currently not dispatched by TextEventDispatcher)
2. compositionupdate
3. compositionend
4. compositionstart
5. compositionupdate
6. compositionend
7. keyup
This is similar to Chromium, although, Chromium includes the second InsertText() call into the first composition, we need to fix it later due to risky.
MozReview-Commit-ID: GL42cU2WIL0
--HG--
extra : rebase_source : 2063c56166f6c9ccee25a74e1d29f94daa6b159c
Send the size from PMGetAdjustedPaperRect to the child to use as the page size.
Add an Mac implementation of GetEffectivePageSize that returns the adjusted dimensions.
MozReview-Commit-ID: GgTFgBzkxTy
--HG--
extra : rebase_source : 9b6e3200698a695d3ca03f3848060083b8fe4ae6
nsPrintingPromptServiceX doesn't use Objective-C, so we should change to C++ instead.
Also, nsPrintDialogServiceX::ShowPageSetup should have NS_OBJC_BEGIN_TRY_ABORT_BLOCK_NSRESULT.
MozReview-Commit-ID: 33LfNFmiUTQ
--HG--
rename : toolkit/components/printingui/mac/nsPrintingPromptServiceX.mm => toolkit/components/printingui/mac/nsPrintingPromptService.cpp
extra : rebase_source : 7ab7e3aeed81afc70d02bd262d87d6858380bb01
Adds serialization of native print settings values so
that correct page size, scaling, orientation are sent
to the child after the print dialog is displayed.
Changes the Mac print dialog code to load native
print settings from the "print.macosx.pagesetup-2"
pref and ignore what is passed in.
Overwrites the scaling percentage specified in
the print dialog when "Ignore Scaling and Shrink to
Fit Page Width" is checked.
Scaling on Nightly (remote printing) needs more work
to be done in a follow up bug.
MozReview-Commit-ID: B12ZeHuiYFJ
--HG--
extra : rebase_source : baa2a5865b29db8914fca1242af59674f9630c8e
Send the size from PMGetAdjustedPaperRect to the child to use as the page size.
Add an Mac implementation of GetEffectivePageSize that returns the adjusted dimensions.
Add an Mac implementation of SetPaperWidth and SetPaperHeight so that adjusted dimensions can be manually set for reftest-print.
MozReview-Commit-ID: GgTFgBzkxTy
--HG--
extra : rebase_source : 66d5b2f8216ebd28401aec9bbb78c5ad32dd666c
Vietnamese Telex perhaps referes this result and change its behavior. When typying something, Telex starts composition on Chrome but may not behave so on Gecko.
Fortunately, Chromium just returns some attributes when validAttributesForMarkedText: of NSTextInputClient [1] but it doesn't return these styles when attributedSubstringForProposedRange: of NSTextInputClient is called (always returns non-styled plain text) [2]. Therefore, this patch does not touch IMEInputHandler::GetAttributedSubstringFromRange().
*1 <7d85f23cb0/content/browser/renderer_host/render_widget_host_view_mac.mm (2936)>
*2 <7d85f23cb0/content/browser/renderer_host/render_widget_host_view_mac.mm (3036)>
MozReview-Commit-ID: 1gPIiu4Qbud
--HG--
extra : rebase_source : 5336eea303ee157959941dcc4bda2a0931f1f532
Vietnamese Telex IME handles Backspace key immediately after inputting a word even when there is no marked text. At this time, it tries to replace the word with specific string. In such case, our editor shouldn't remove anything at handling the Backspace keypress event.
For avoiding this issue, InserText() should dispatch a set of composition for inserting the specified text into the range. Then, editor won't perform any action of the key.
Additionally, when a Backspace keydown tries to remove the last character of the word, Telex removes it with a composition. At this time, it creates dummy marked text "a" and make it empty later. So, in this case, InsertText() won't be called, therefore, we need to consume the Backspace keypress when SetMarkedText() is called for preventing removing the previous character of the word.
MozReview-Commit-ID: LfeEHDWn0cZ
--HG--
extra : rebase_source : 4753262ef16bc3875754ae38e966d8512947ad89
This is the first step in using these functions without having a
LayerManagerComposite at all.
MozReview-Commit-ID: 2zkuB7Ox4Ut
--HG--
extra : rebase_source : b23988275f5851a2fd30bd3e8a9931107a224c66
widget/cocoa/nsAppShell.mm:113:47 [-Wmismatched-parameter-types] conflicting parameter types in implementation of 'nextEventMatchingMask:untilDate:inMode:dequeue:': 'NSEventMask' (aka 'unsigned long long') vs 'NSUInteger' (aka 'unsigned long')
NSWindow's nextEventMatchingMask method expects a parameter of type NSEventMask, not NSUInteger, when building x86_64 with SDK 10.12:
https://developer.apple.com/reference/appkit/nswindow/1419304-nexteventmatchingmask
TextInputHandler::InsertText() dispatches a set of composition events when a key press causes 2 or more characters (Note that InsertText() is typically called only when IME is available because it's called via [NSResponder interpretKeyEvents]). However, this is different from the behavior of Windows. On Windows, NativeKey dispatches two ore more eKeyPress events in this case.
So, for consistency between platforms, TextInputHandler should dispatch eKeyPress events in such case.
MozReview-Commit-ID: EMvaL7sklKf
--HG--
extra : rebase_source : 0309d32d692a2394f53cd59216c6e774068e452b
This converts |nsITransferable.flavorsTransferableCanExport| and
|nsITransferable.flavorsTransferableCanImport| to return a |nsIArray|.
|nsIFormatConverter.getInputDataFlavors| and
|nsIFormatConverter.getOutputDataFlavors| are updated as well.
The cause of bug 1309515 is, HandleKeyDownEvent() dispatches eKeyPress events even after InsertText() dispatches composition events via InsertTextAsCommittingComposition().
Therefore, this patch consumes the current key event after dispatching composition events.
Note that for consistency with Windows, InsertText() should use eKeyPress events rather than composition events at least in this case. However, changing the behavior has some risk. So, we should fix this bug with the safest hack for uplift.
MozReview-Commit-ID: 7FYR5N2lATe
--HG--
extra : rebase_source : 4485bd76a68567e8c20a84c2fbca78c626f592c5
This guarantees that the runnable will be processed before shutdown leak checking.
MozReview-Commit-ID: B89AcDUWb3y
--HG--
extra : rebase_source : bfbd311fba367c1856cc5d972e6e999ccd4de1ac
IMEInputHandler shouldn't append any ranges to dispatch empty composition event since empty clause information may make TextComposition confused. Additionally, it doesn't need to append caret range because CompositionTransaction always sets caret at start of composition when the composition string is empty.
MozReview-Commit-ID: FkLWePXZGJf
--HG--
extra : rebase_source : ede2687618ca072b40ba6d21861f1fc97296c416
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 2a94a47f1e7fe986d1efc3854c72968a3e28e365
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 : f276e1629fcd0ffccb8c8dbec7bba6639a5ebd9f
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 : 82733f682c9e254e20354cc6908955a1e7485ee7
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : ccf64aaa9364d096e1f060ef77be7e8455b11e1f
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 : b8a0d9a49b31929dd06af9e61fc57f484af7671d
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : e98b7f9970a920c39e941bb531dfc098125913d1
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
Start offset of composition string is fixed when composition string becomes non-empty in focused editor. In other words, until composition string is fixed, composition start offset may be changed from selection start offset at dispatching compositionstart event. Especially, in e10s mode, pending keyboard events usually change composition start offset.
So, while there is composition, IMEHandler should use query events querying text rect or text content relative to actual start offset of composition string because native IME believes composition string at selection selection start when starting composition in the main process.
MozReview-Commit-ID: 3hinwozl9Ow
--HG--
extra : rebase_source : 4b79dd4f53aa51edfc78ff08c07a710160a8de01
The only implementation of SetSizeMode() that can fail is the nsCocoaWindow
one, on an Objective C exception, which is unlikely and can be swallowed.
This allows some nsGlobalWindow functions to become infallible as well.
--HG--
extra : rebase_source : 85d54185f63d2c138ee3f3e0e0bfe3b5e805a981
They don't need to be NS_IMETHOD, but they should be MOZ_MUST_USE. Adding the
latter catches a few missing checks, which the patch adds.
The patch also gives PuppetWidget an InfallibleCreate() function, which makes
the infallibility of PuppetWidget creation clear.
This patch makes GetBounds(), GetScreenBounds() and GetClientBounds() more
obviously infallible, like existing functions such as GetNaturalBounds() and
GetClientSize(). This results in clearer behaviour in nsCocoaWindow.mm if
Objective C exceptions occur. Along the way, the patch removes some useless
failure checks for these functions.
The patch also removes the NS_IMETHOD from GetRestoredBounds and makes that
function MOZ_MUST_USE.