When you start new composition during converting with Mozc in e10s mode, the following things occur:
1. Mozc commits previous composition.
2. Gecko dispatches eCompositionCommit event.
3. Mozc sets new composition string (skipping composition start signal).
4. Gecko dispatches eCompositionStart and eCompositionChange event.
5. Selection is changed asynchronously.
6. Gecko sets position of IME windows.
At #4, Gecko stores start of composition as selection start, then, trying to adjust it at #5. However, new selection is caret position in new composition string. Therefore, it's not used for the adjustment. This causes that stored composition start offset is always the start of the previous composition (if the previous patch didn't change EnsureToCacheSelection() behavior). So, IMContextWrapper needs to compute proper composition start offset in this case.
The simplest fix is, modifying selection at #2 as which will be occurred in focused editor. So, this patch makes the selection cache collapsed to the end of committing string.
Note that actual selection may be different if JS changes selection and/or the text in the focused editor. However, it doesn't matter. IMContextWrapper should behave as expected while current composition is active.
MozReview-Commit-ID: 221mDUd8yRP
--HG--
extra : rebase_source : 571b2de85ed6ea1fdadea73b7f95507937cc60e9
IMContextWrapper::EnsureToCacheSelection() always queries actual selection when the caller needs selected string. However, this may be expensive and this is bad behavior for the following patch because it wants to emulate selection range until receiving next selection change notification.
Therefore, this patch makes IMContextWrapper::Selection store selected string instead of just its length like other native IME handlers
Additionally, this patch renames IMContextWrapper::mSelectedString to IMContextWrapper::mSelectedStringRemovedByComposition for making the difference between it and the new string in Selection clearer.
MozReview-Commit-ID: 3bygvW7sKf4
--HG--
extra : rebase_source : b0835b8c1607ecd647444a4d984980943a6fd570
No functional changes intended in this patch. It merely simplifies the
additional patch that we'll need to update gecko past WR cset 0bf6655,
and saves some potential manual rebasing work.
MozReview-Commit-ID: Km8dBotP3NQ
--HG--
extra : rebase_source : 77c34ec1cbbc1c0fe4d1971feb131d30c97f0d66
This is remaining cases of bug 1312302. TSF may set focus to context when it receives focus related message. In such case, TSF tries to retrieve selection but TSFTextStore::GetSelection() returns E_FAIL due to still not initialized, TSF crashes.
This patch moves the hack to TSFTextStore::GetSelection() and restrict to work only on problematic versions of Windows 10.
MozReview-Commit-ID: 6cTiZ4HCO18
--HG--
extra : rebase_source : 733377be55d52c43ef90d6e949cb851cf4c6dcb2
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
The '-moz-windows-accent-color-applies' media query matches when the Windows 10
accent color should be used as the background of the title bar.
MozReview-Commit-ID: GM7nZij6MhQ
Due to the fix of bug 1376424, ContentCacheInParent::FlushPendingNotifications() may be called when aWidget is nullptr. In this case, it doesn't need to do anything. So, it should ignore the call.
MozReview-Commit-ID: Fj3J76v6Xuk
--HG--
extra : rebase_source : 18c722628a3ae8fa50beca3908d5e732cec404d9
Otherwise, with the next patch, xpcshell tests crash because
WakeLockListener::Shutdown tries to Release() nullptr.
MozReview-Commit-ID: AmD5b6NUqnP
--HG--
extra : rebase_source : dd856ea37e793a8c40f2baf1eb001f96b4d0ee35
The problem is, only when requesting IME to commit or cancel composition is handled synchronously, TabParent does not send the dispatched eCompositionCommit(AsIs) event to the remote process. Therefore, TabParent (and ContentCacheInParent) never receives the message from the remote process.
This patch makes TabChild notifies TabParent of eCompositionCommitRequestHandled special event message after TabChild dispatches eCompositionCommit into the DOM tree. Then, ContentCacheInParent should decrease mPendingCompositionCount and mPendingEventsNeedingAck as usual composition event messages.
MozReview-Commit-ID: 7ec5HPiE687
--HG--
extra : rebase_source : a9366abf6f8feec2d6ac639fd37f5b5c6ddd9586
TextComposition in the main process is destroyed when the main process sends eCompositionCommit(AsIs) to focused remote process. Therefore, ContentCacheInParent::mCompositionPendingCount is never 2 or more now.
It may cause ContentCacheInParent::Assign() setting older composition's start offset to current composition's start offset in the main process.
For making uplift the following patch easier, the wrong patch should be backed out first.
MozReview-Commit-ID: IHWc7qZBQtc
--HG--
extra : rebase_source : d3936fa82ed670217b711d15bbb0201a8741501b
When keyboard apz is disabled, we don't need to calculate focus targets and
we don't need to update focus state. It should be harmless even if it's done,
but I think it's good to not add something on this critical path that doesn't
do anything.
This commit also disable keyboard map generation in this case too for similar
reasoning. This has the side effect that you can't turn on keyboard apz without
doing a restart.
MozReview-Commit-ID: LxmofT2g7qs
--HG--
extra : rebase_source : 719d29efd80498b824fee03a5be1c1fd05c83074
extra : histedit_source : 7ad71a19782fc6dd203207afbdc7a73a936b3e04
This commit adds code for keyboard scroll animations and computing the delta
needed for a keyboard scroll action. Keyboard scrolling behavior is more complex
with scroll snapping, so we don't support async keyboard scrolling when we have
scroll snap points.
MozReview-Commit-ID: 97CpprCBp2A
--HG--
extra : rebase_source : 154b2c6b5a6c587fca011ab885c8d46ba6b4d80a
extra : histedit_source : 87ba53fe89069a47751d9ce25fc344011fb0f4de
Focus can change at any moment in a document. This causes non-determinism and
correctness problems for doing keyboard apz scrolling. To get around this, we
will maintain deterministic behavior for focus changes initiated by input events
and see if we can get away with more non-determinism for things like `setTimeout`
In order to do this, we disable async keyboard scrolling when an input event is
processed that could have a event listener. We then attach a sequence number to
that input event and dispatch it to content. In content, we record the highest
sequence number that we have processed from an event, and send that on each focus
update. Using this, we can determine in APZ if we have a current focus target or
if we are still waiting for an input event to be processed and focus to be
reconfirmed.
MozReview-Commit-ID: CWcu8YEFQz4
--HG--
extra : rebase_source : 8c54a619bd4f5ee892f0cc8768a10f3e1e4e0b59
extra : histedit_source : 601ca293a028787883841adc6b40e62c0cc829e5
This commit makes it so we initialize, send, and store a KeyboardMap for every
APZCTreeManager for later keyboard event processing.
This is a naive approach so it may be worth improving.
MozReview-Commit-ID: CYTbLL3wRlC
--HG--
extra : rebase_source : 016b80a2a209d4fb5b92bc3adb95bd2dbb4399e0
Keyboard scrolling works by first dispatching a key event to the focused element
of the page. It is then caught by a XBL binding put on the chrome event handler of
every window. The XBL binding searches through all of its handlers to find one
that can handle the keyboard event. The matching binding has a command string
which is dispatched to the nsGlobalWindowCommands which dispatches to PresShell
which does the actual scrolling.
To do this asynchronously, we need a representation of the XBL handlers that can
be applied to a KeyboardInput to get a KeyboardAction.
This commit adds KeyboardShortcut for this purpose. KeyboardShortcut is designed
to be compatible with nsXBLPrototypeHandler and to only handle the specific cases
we care about for keyboard scrolling. If a XBL handler runs javascript or does
anything else we cannot handle in an OMT situation, then we create a
dispatch-to-content KeyboardShortcut.
MozReview-Commit-ID: 1qzywS3QHVp
--HG--
extra : rebase_source : 8ea4f85c02d04ce5e0fa6e430c44ac920269dd9f
Every event type handled by APZ needs to have a InputData type. This commit
adds a new KeyboardInput type that stores the minimum fields needed to match
keyboard shortcuts.
MozReview-Commit-ID: 3KUnH4sWrST
--HG--
extra : rebase_source : 710274199a1ced0716abe02e9d6aaea0d31c9498
The '-moz-windows-accent-color-applies' media query matches when the Windows 10
accent color should be used as the background of the title bar.
MozReview-Commit-ID: GM7nZij6MhQ
--HG--
extra : rebase_source : ee8089ef876d0887e2c0d063015145d17eefa612
When IME commits composition and restarts composition immediately, query event with relative offset doesn't work as expected until the commit is handled in the remote process.
Therefore, this patch makes ContentCacheInParent store the last commit string length until it's handled in the content. Note that ContentCache doesn't need to store all commit string lengthes which have not been handled in the remote process yet because it's important and possible to return next character of commited composition only when there are not 2 or more pending compositions. Even if there are, i.e., the remote process is too busy, ContentCacheInParent doesn't have necessary character rect.
MozReview-Commit-ID: 8gBr8kO4JcF
--HG--
extra : rebase_source : f4748928c07ee284a5c312b89291e3a4fb8f790d
I found invalidateCharacterCoordinates in NSTextInputContext. It's available 10.6 and later.
Calling this API does NOT make visible candidate window follow window move nor something to change layout, though. But we should call it.
MozReview-Commit-ID: KbllLDwlMOz
--HG--
extra : rebase_source : 175377bf7dd703dcd304ffbb8648e350080c07fc
On macOS, we fall back eKeyPress event to native menu. Therefore, widget always requests a reply from remote process because it's difficult to check if the eKeyPress event will be sent to a remote process actually. If it's not sent to any remote processes, PresShell needs to dispatch the event into the DOM tree. Additionally, even if it's marked as "waiting reply from remote process", it needs to dispatch the DOM event in the main process first because we need to check if the key combination is reserved by chrome (if it's reserved, the eKeyPress event shouldn't be fired in the remote process).
Therefore, this patch makes EventStateManager::PreHandleEvent() resets the state when focused content isn't in any remote processes and the event's propagation hasn't been stopped.
Additionally, this patch makes PresShell::HandleEventInternal() checks WidgetEvent::PropgationStopped() with WidgetEvent::IsWaitingReplyFromRemoteProcess() before dispatching the event into the DOM tree.
MozReview-Commit-ID: FmgL3rCuQ8y
--HG--
extra : rebase_source : aa8d6b924fc78d1d9dd35a35c92976c35c758657
nsMenuBarListener::KeyPress() is eKeyEvent listener in the system event group. If the target is a remote process, it shouldn't handle accesskey immediately because preceding eKeyDown event may be consumed in the remote process or eKeyPress event itself may be consumed in the remote process.
This patch makes nsMenuBarListener::KeyPress() mark eKeyPress event as "waiting reply from remote process" only when the event matches with a menu item's accesskey and it will be send to a remote process later. Then, reply event should be handled in this method if it's available.
MozReview-Commit-ID: KOpCVgElnca
--HG--
extra : rebase_source : 881ec01f5c8e21c790bf9a8c3167d6c3f932524a
Currently, access key is handled in EventStateManager::PreHandleEvent() with eKeyPress event, i.e., before dispatching it into the DOM tree, if the access key is registered in EventStateManager. So, the main process does not check if the preceding eKeyDown event is consumed in focused remote process.
When preceding eKeyDown event is consumed in the main process, eKeyPress event won't be dispatched by widget. However, if remote process has focus, it's impossible widget to stop dispatching eKeyPress event because preceding eKeyDown event hasn't been handled in the focused remote process yet. Therefore, main process needs to post eKeyPress event to check if preceding eKeyDown event was consumed. When eKeyPress event is marked as "waiting reply from remote process", TabChild sends it back to the main process only when preceding eKeyDown event wasn't consumed. So, only when eKeyPress event is back to the main process, main process should handle accesskey with it.
This patch makes EventStateManager::PreHandleEvent() check if a remote target has focus before handling accesskey. If a remote process has accesskey and there is an accesskey matching with eKeyPress event, it marks the event as "waiting reply from remote content" and stop propagation in the process.
Finally, when eKeyPress event is sent back to TabParent, TabParent::RecvReplyKeyEvent() calls EventStateManager::HandleAccessKey() before dispatching the reply event into the DOM tree.
MozReview-Commit-ID: KsOkakaIVzb
--HG--
extra : rebase_source : 7e0c6966a1bde085e34d45bca4b0166b9fc2f3f1
EventStateManager checks if every keypress event's modifiers match with access key modifiers which are in prefs. Moving related methods of this to WidgetKeyboardEvent makes EventStateManager simpler and we can hide the NS_MODIFIER_* constants (they may make developers confused between Modifiers of WidgetInputEvent) into WidgetEventImpl.cpp.
MozReview-Commit-ID: 23NUQ51lJ1M
--HG--
extra : rebase_source : 341f3764ef62575577572d8b349159e2d5512b26
All reftests that are still failing with APZ enabled are annotated with
a bug number that is tracking the fix.
MozReview-Commit-ID: 8QU15LHVy1t
--HG--
extra : rebase_source : 71908ca38e96e0f6f5a341605e70c3f6670b9237
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
This patch fixes failures for widget/tests/test_composition_text_querycontent.xul when it is run on ubuntu 16.04. It adds some missing handling for pre-test position change notifications and also adds some handling for after-test position change notifications.
MozReview-Commit-ID: 1t8NuxJqkOo
--HG--
extra : rebase_source : ddae0da39a087c5742e31fbae9d7930b95695f1e
Once the |aPayload| argument to profile_add_marker() became a UniquePtr the
default value of nullptr caused compilation difficulties that could only be
fixed by #including ProfilerMarkerPayload.h into lots of additional places
(because the UniquePtr<T> instantiation required the T to be fully defined). To
get around this I just split profile_add_marker() into two functions, one with
1 argument and one with 2 arguments.
The patch also removes the definition of PROFILER_MARKER_PAYLOAD in the case
where MOZ_GECKO_PROFILER isn't defined. A comment explains why.
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
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
ContentCacheInParent::mPendingCompositionCount is now managed with composition events which TabParent received. However, TextComposition doesn't dispatch composition events after coming request to commit active composition. Therefore, composition is committed forcibly in a remote process over 255 times, the main process crashes.
It's the safest way to use TextComposition to manage ContentCacheInParent::mPendingCompositionCount.
MozReview-Commit-ID: DEhzYcK1zcW
--HG--
extra : rebase_source : a47891b1d620bbe4e380e73134ec6da5d21f4ea9
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
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
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
1) Provide a BaseHlsPlayer as the interface used in related java wrappers.
2) Create and get the player instance from factory via reflection to decouple the source code dependency.
MozReview-Commit-ID: 5wsHSOjSeXV
--HG--
extra : rebase_source : 730fd8ba1c200d7bcc3b6c3393eca0ada69086a4
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
Between nsIDocumentObserver::BeginUpdate() and nsIDocumentObserver::EndUpdate(), IMEContentObserver can cache added nodes as a range if they are consecutive nodes. Even if a node is removed, a data node is changed or attribute is changed unexpectedly, IMEContentObserver can post text change of the added node range and handle it normally.
MozReview-Commit-ID: IttDHBkr92Y
--HG--
extra : rebase_source : f0849d5fab0b28bdfa311cf833a216d43b9215d2
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
This fix a mistake that goes back to the original code from bug 174585
(gecko-dev 9611b23530, 2005-08-20).
(This makes me wonder how important the code is in the first place if it
didn't work correctly.)
MozReview-Commit-ID: B6q0o5n5hDw
Now that, thanks to bug 1367577, we have the theme constants in an enum,
we can make these arrays smaller rather than assuming that the constants
might use any valid uint8_t value.
MozReview-Commit-ID: A6GjTarVurc
See comments in the header file.
This also clears out mSafeWidgetStates in ThemeChanged since that seems
like a good thing to do, and marks nsNativeThemeGTK as final.
MozReview-Commit-ID: 5Zne4eGbGlh
This refactors the two nearly-identical callsites into a method so that
I can do caching in that method in the next patch.
Note that there was a slight difference between them in that the
aWidgetFlags parameter to GetGtkWidgetAndState was only passed from one
callsite. However, given that the aState parameter is null, this
doesn't cause any behavior differences. (Some controls in
GetGtkWidgetAndState null-check aWidgetFlags and some don't!)
Note also that this makes it always assign a result (often zero). This
is fine for both callsites; GetWidgetPadding previously assigned zero
right before the call, and GetWidgetBorder did so at the start of the
function (and wasn't modified in between, since it was immediately
before the switch that the modified code is a case in).
MozReview-Commit-ID: IKurwry3UTi
It causes an assert failure in gtk which prints to the console.
MozReview-Commit-ID: A4106Z4rT36
--HG--
extra : rebase_source : 642c94a95cfa3939bc475e9139ee63caa78e3005
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
These old invalid prefs were caused by us not clearing out old inch page size prefs when the
user switched to a standard mm page size (for example A4).
This fix uses the fact that an old print_paper_size_type pref was removed at the same time
to trigger a one off sanitization.
Authored by Andrew Comminos <andrew@comminos.com>
MozReview-Commit-ID: FIQBHSXgjMh
--HG--
extra : rebase_source : 1ae73bed3b2b933d11803ae3b93afbf3d1e1f570
This preference is default to false and allows to experiment with transparent widgets on Gtk.
Original patch autor is Andrew Comminos <andrew@comminos.com>.
MozReview-Commit-ID: JZkCjBWny3m
--HG--
extra : rebase_source : 116c4977d7d7f3927e6a4df203584d8b9c9ad57b
Authored by Andrew Comminos <andrew@comminos.com>
MozReview-Commit-ID: FIQBHSXgjMh
--HG--
extra : rebase_source : 22885a2846ec0bc718196d6e16bacb37b0410b25
This preference is default to false and allows to experiment with transparent widgets on Gtk.
Original patch autor is Andrew Comminos <andrew@comminos.com>.
MozReview-Commit-ID: JZkCjBWny3m
--HG--
extra : rebase_source : 18a3dd1ecb2ef87910307e3085a343a4d75403af
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
Synth mouse move events are triggered by layout changes, which should
not interrupt reflow.
MozReview-Commit-ID: 5VFJFOXH3BB
--HG--
extra : rebase_source : ac976b508fac0aa661b75c630c55528d518ec52f
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