This patch also adds logging into ResolveJunctionPointsAndSymLinks to help diagnose issues that
might arise if the resolution fails or the path is not usable for some reason.
nsXPIDLStrings are marked as VOIDED upon initialization. Most of these local
nsXPIDLString variables are immediately set via getter_Copies(), which will
either assign a string value (using Adopt()) or do SetIsVoid(). These can be
trivially converted to nsString, which will get the same treatment.
The patch suitably converts the remaining nsXPIDLString local variable as well.
--HG--
extra : rebase_source : 5fff9f2c6844559198f601853f8db08564add7d5
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
Although this is only known to affect buttons with builtin child widgets, it
is difficult to audit all GTK widgets for similar situations, and so the same
defense is applied to all widgets.
MozReview-Commit-ID: LMVXX3UYqR9
--HG--
extra : rebase_source : d327addad8d2b0e070c6ca86c6e38271c8431a23
Android now supports telling an IME that it shouldn't store user-entered content into it's dictionary/language model/etc. and we want to automatically enable this in private browsing.
As the code that handles input on Android doesn't have any notion of tabs (and therefore of the difference between normal and private tabs), the best way to get that info across is to retrieve it directly within the IMEStateManager from the corresponding document and store it in the inputContext, which is then passed to Java for Fennec to handle.
Implementing this within Gecko also has the benefit that this part of the code can be used by other platforms as well should they want to support similar features in the future.
MozReview-Commit-ID: DsxjC4Ma7DR
--HG--
extra : rebase_source : f0940cb40170ab32cf5a172d07a61d083427be8a
When WebRender creation is failed, WebRender is disabled in gecko. There is a case that WebRenderBridgeParents exist when WebRender is disabled. To handle this, gecko needs to rebuild all CompositorSessions.
There is also a problem related to gfxVars::UseWebRender on compositor thread. If e10s is enabled, but no-gpu process(default on linux and mac), gfxVars::UseWebRender change is soon notified by compositor thread tasks. If WebRender creation failure happens at 2nd WebRender creation, several WebRenderBridgeParents for 1st WebRender could exist. IPC messages from WebRenderLayerManager are normally async, then there is a chance that the WebRenderBridgeParents receive the messages after the gfxVars::UseWebRender change. Further the gfxVars::UseWebRender change in content process could be delayed than WebRenderBridgeParents, then content process does not have a way to stop sending PWebRenderBridge IPC until the change of gfxVars::UseWebRender is received. WebRenderBridgeParent related tasks handle the message, but some tasks are done based on gfxVars::UseWebRender. At this time, gfxVars::UseWebRender returned false on compositor thread, then it cause unexpected result for WebRenderBridgeParent and WebRender. To addres this inconsistent situation, WebRenderBridgeParent related tasks on compositor thread stop to use gfxVars::UseWebRender.
billm reports that the runnable in this code is firing a lot, and since we
don't support XP/Vista we're not benefiting from this overhead.
MozReview-Commit-ID: Bpw1E9DxPpD
--HG--
extra : rebase_source : 580ef086e8d9ce12c42724c6671d9de87038beb4
Use the UI thread's tid for checking if we're on the UI thread in Gecko.
This lets us get rid of `GeckoThread.registerUiThread`, in order to
avoid a race where we check for UI thread before `registerUiThread` is
called.
MozReview-Commit-ID: 11gAWgx4UZo
Before this change we were trying to change the settings from both the content
and parent processes, so this doesn't change any functionality. This allows to
remove access to the com.apple.PowerManagement.control mach service from the
content process.
MozReview-Commit-ID: 3DOhqG5U6oz
--HG--
extra : rebase_source : dee0b97c444ae95cfc8f80cb0fb99aa9e2658d51
To make the HeadlessCompositorWidget work under Windows as well as Linux, I had
to change the way that I hooked it into the existing CompositorWidget system.
Under GTK, the CompositorWidgetInitData and CompositorWidgetDelegate types
provided the information needed by the headless compositor widget already (the
widget client size). On Windows, however, the definitions of these types
differ, and the client size information is simply retrieved from the platform
APIs when needed.
After this patch, CompositorWidgetDelegate is renamed to
PlatformCompositorWidgetDelegate, and a new base class called
CompositorWidgetDelegate is added with "AsPlatformSpecificDelegate()" and
"AsHeadlessCompositorWidget()" methods. In non-headless mode, widgets use
AsPlatformSpecificDelegate() to access the Windows- and GTK-specific delegate
APIs. In headless mode, AsHeadlessCompositorWidget() is used to access the
singular CompositorWidget implementation for headless. Meanwhile, the
CompositorWidgetInitData IPDL type is made into a union which always contains a
headless-specific HeadlessCompositorWidgetInitData struct and under GTK and
Windows also contains an {X11,Win}CompositorWidgetInitData struct.
This also includes a small patch to ensure that the GPU process and
hardware-accelerated compositing are always disabled under headless mode. These
features weren't activated by default in the Linux environments I tested in, but
did end up activating (and then promptly crashing Firefox) when I tested on
Windows.
MozReview-Commit-ID: CocPoHBDV7H
--HG--
extra : rebase_source : 4581fa63aa3a9f32a8dc2672015a35b9be01b20f
It seems that my reworking of how the z-index events are sent in the patch
pertaining to active window tracking made it so that we can have headless
widgets default to being invisible again, which matches the behavior on all
other platforms. This then allows us to avoid applying size mode change side
effects while a window/widget is invisible, matching the behavior on Windows and
allowing the relevant web platform tests to pass despite the low screen
resolution with which we run Windows VMs in testing (eg.
open-features-non-integer-height.html).
MozReview-Commit-ID: 3xnaEn7RImP
--HG--
extra : rebase_source : 0c573f92b02a58aca28c71dd897ae7a443f50844
This fixes a series of issues uncovered by the Web Platform Tests.
The most immediately noticeable symptom was that, during shutdown, PuppetWidgets
on the client side attempted to delete shadow layers that were never created on
the compositor side. The usage of BasicLayerManager in all other widgets due to
headless mode meant that the PLayerTransactionParent was never initialized with
a layer manager, and thus discarded all transaction messages it received but not
delete layer messages.
The effects of only using BasicLayerManager in headless mode also showed up in
the web platform reftests, which ended up as blank white boxes in e10s mode as
the compositor thread never received paint instructions. Switching over to
using ClientLayerManager in headless mode causes these paint instructions to be
relayed.
In order to make ClientLayerManager work under headless mode, it was necessary
to implement a HeadlessCompositorWidget and hook that up to the CompositorWidget
creation function in widget/gtk. A follow-up patch will be necessary to hook up
the same for the other supported widget platforms.
MozReview-Commit-ID: 8vB3lrxP7iX
--HG--
extra : rebase_source : 4013aa856943c983b44266c4a83436b253bc7ab1
This is necessary for focus events to propagate correctly. Otherwise,
/2dcontext/drawing-paths-to-the-canvas/drawFocusIfNeeded_004.html in the
Web Platform Tests fails, for example.
MozReview-Commit-ID: 69GItIaQWfr
--HG--
extra : rebase_source : 24eb487d35b273c8bd128c0e7450946b36467b7b
Every other widget backend ensures widget size is bounded to screen size, but
this check was missing from headless.
MozReview-Commit-ID: 6bKIAkdRxoO
--HG--
extra : rebase_source : 6494a347aba323b977b845a1b70555fb1ab53864
Currently, TSFTextStore::GetIMENotificationRequests() tries to return notification requests for focused text store. However, if there is sEnabledTextStore, all notifications will be sent for it. Therefore, TSFTextStore::GetIMENotificationRequests() should return notifications for sEnabledTextStore without checking focused text store in the thread manager.
For example, we try to keep active composition even if we're being inactivated because Windows steals focus from us when our main process becomes busy but user may want to continue to compose the composition after our process becomes available.
Additionally, if TSFTextStore::GetIMENotificationRequests() doesn't return IMENotificationRequests::NOTIFY_DURING_DEACTIVE, sEnabledTextStore will be broken by NOTIFY_IME_OF_BLUR which will be sent by IMEStateManager::OnChangeFocusInternal(). However, when we're being activated, NOTIFY_IME_OF_FOCUS won't be notified because focused remote process keeps having IMEContentObserver. Therefore, sEnabledTextStore won't be recreated and IME becomes unavailable.
Therefore, while sEnabledTextStore is not nullptr, TSFTextStore::GetIMENotificationRequests() needs all notifications even if it loses focus in the thread manager.
MozReview-Commit-ID: CC6gJIpHxUO
--HG--
extra : rebase_source : 02559fe8fea81b4247ef27043fc1d995981a9ba4
