From 10.10.3, macOS supprts looking up dictionary by force touch. So we should support it because this is supported by Chrome and Safari.
MozReview-Commit-ID: AcAhieMXOwe
--HG--
extra : rebase_source : 79c55830dfa023165731269780d813956e4e26f2
Since our platform requirement is Windows 7+, we don't need GetProcAddress for gesture APIs. But nsWinGesture still uses GetProcAddress for Win7+ API.
MozReview-Commit-ID: 1COJqM4NJTD
--HG--
extra : rebase_source : d915c1f74f6f3f10287ae6d08892499c3d3e8da6
Built pdfium_ref_x86.dll and pdfium_ref_x64.dll from google source tree. Use
them to generate an EMF as the reference.
MozReview-Commit-ID: GoaxU6nWXYM
--HG--
extra : rebase_source : 441d72cd409e105337eed7d763a29ef329ba2d58
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is only used in ways that nsCStrings can also be used
(i.e. no null checks or implicit conversions to |char*|).
In every case the patch trivially replaces the nsXPIDLCString with an
nsCString. (Also, there are a couple of unused nsXPIDLCString variables that
the patch simply removes.)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
This line is subtle enough to not be noticeable with light titlebar fills,
and looks out of place with dark titlebar fills.
MozReview-Commit-ID: D0b4O2wry1F
--HG--
extra : rebase_source : 739adb837f8e756fc9619864877fc6faff31d1cf
CompareCacheHashEntry::mCrit[] is the only case where the nsXPIDLString-ness
was important. The patch adds an explicit SetIsVoid() call to that class's
constructor and changes some null checks to IsVoid() checks.
--HG--
extra : rebase_source : e68befcde4dd098bac2a550bc666eaf3bf1298d7
When Gecko started to support Cocoa widget, we needed to use NSInputManager.
That allowed applications to access only focused IME context. Therefore, commit
composition request handler for Cocoa is designed as handling asynchronosly if
it's requested when the window is not active or is being inactivated.
Additionally, the asynchronous handling isn't perfect. We hit some MOZ_ASSERT()
now in some places. E.g., in SelectedRange(), it doesn't assume that it's
called during deactive.
On the other hand, NSInputManager was alreay obsolete and we already stopped using it
(bug 810225). Instead, we're using NSTextInputContext and it allows applications
to access IME anytime. Therefore, if we make IMEInputHandler handles commit/cancel
composition requests synchronsly, that behaves same as the other platforms. So, we
can get rid of macOS specific issue completely.
MozReview-Commit-ID: X7aWmGq95x
--HG--
extra : rebase_source : a472a03e3ef6f424fe73c2d438b8326bed80278d
It wasn't enough to just check for `mWindow` in `OnResumedCompositor()`,
because the `LayerViewSupport` instance itself could have been released.
This patch now checks for both cases.
MozReview-Commit-ID: hSnFUhtp8m
When removing our Windows message loop pumping code in the content
process, a11y code on the MTA thread must have some way to wake up the
main thread. The main thread could be blocked either on a conditional
variable waiting for a Gecko event, or it could be blocked waiting on
a Windows HANDLE in IPC code (doing a sync message send). In the
former case, we wake it up by posting an event to the main thread. In
the latter case, we continue to use the asynchronous procedure call
mechanism.
MozReview-Commit-ID: FN6KWaGo9Zl
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
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is used in ways that rely on the implicit conversion
to |char*|. The patch uses get() and EqualsLiteral() calls to replace the
implicit conversions.
There's some racing going on between compositor methods that use the
XPCOM queue and the disposeNative method that uses the priority queue.
Move everything to the XPCOM queue to fix this condition.
MozReview-Commit-ID: BUxotrpBVsW
Right now we throw NullPointerException with the message "Null native
pointer", but we can save the type of the native pointer in the message
to make it easier to categorize and analyze crashes. This patch uses the
__func__ feature to get the name of a particular template parameter
type.
MozReview-Commit-ID: GNWzIy91OD6
"intl.tsf.hack.ms_japanese_ime.do_not_associate_imc_on_win10" should be unnecessary anymore because it failed to avoid the crash of MS-IME for Japanese but causing other regression. Therefore, this patch removes it completely.
MozReview-Commit-ID: 91jjxfIYReW
--HG--
extra : rebase_source : d261f5bf77c14c41562495574d87364a7bb2d4fc
The messages are routed through nsITabParent, nsIWidget, and IAPZCTreeManager
(the latter possibly remoted via PAPZCTreeManager if out-of-process compositing
is used).
MozReview-Commit-ID: 1zXzLa1fqpG
--HG--
extra : rebase_source : c482816ecbaec0a889d817851ee15be186b2a49c
This parameter isn't used by any implementation of onDispatchedEvent,
and keeping the parameter makes later refactorings in this bug more difficult.
MozReview-Commit-ID: 90VY2vYtwCW
This is similar like the previous patch, but for the 8-bit string variants.
Also, it changes assignment to Adopt() in GetCString() and GetDefaultCString()
to avoid an extra copy.
--HG--
extra : rebase_source : eba805c3a7b809d5ccd6e853b1c9010db9477667
WebKit's Speedometer benchmark updates textbox to emulate text input. So it also updates caret position with focus. And, nsCaret always gets current blink time when reseting caret via LookAndFeel.
When profiling speedometer benchmark, GetCaretBlinkTime somestimes show profiling stack. This API gets data from kernel mode, so this isn't faster.
So, we should cache caret blink rate.
And when changing this rate via control panel, WM_SETTINGCHANGE is posted. So we should update this cache via this message.
MozReview-Commit-ID: IEIi25RvR1g
--HG--
extra : rebase_source : 4bc506acd67f2737cf44dc2a667c938efc7b4024
Because we want to remove nsAdoptingString. We have other variants that don't
use nsAdoptingString, which can be used instead. There are three basic
patterns.
1. The easiest case is when we don't check for success.
> nsAdoptingString s = Preferences::GetString("foo");
> foo(s);
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> foo(s);
2. The next case is when we check if the result is empty.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s.IsEmpty()) { ... }
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> if (s.IsEmpty()) { ... }
3. The final case is when we null check the result.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s) { ... }
becomes:
> nsAutoString s;
> nsresult rv = Preferences::GetString("foo", s);
> if (NS_SUCCEEDED(rv)) { ... }
The patch also avoids some UTF8/UTF16 conversions in a few places.
--HG--
extra : rebase_source : f339b1a3dda4dc93979d38c30c001fbe77485b55
This is basically a cosmetic change; references are the normal way to do string
outparams.
--HG--
extra : rebase_source : ffc5945f269bdcd3d4116755b56713e87a44b6cd
When aEvent.mNativeKeyEvent of nsWindow::GetEditCommandsRemapped() is nullptr, that means the event was created without a native event. Typically, chrome script created the event. In such case, we should not execute native key bindings because doing it exposes the OS settings to chrome script because that might cause some privacy issue. Therefore, the method should do nothing with such event.
MozReview-Commit-ID: 7ZHZjZ3ligT
This patch replaces four functions of the name AssignWithConversion which
are essentially wrappers around CopyASCIItoUTF16 and LossyCopyUTF16toASCII
with direct calls to the latter two functions. The replaced functions are:
void nsCString::AssignWithConversion( const nsAString& aData )
void nsString::AssignWithConversion( const nsACString& aData )
void nsTString_CharT::AssignWithConversion(
const incompatible_char_type* aData,
int32_t aLength = -1);
The last of the three exists inside the double-included nsTString* world and
so describes two functions, giving four in total.
This has two advantages:
* it removes code
* at the call points, it makes clear (from the replacement name) which
conversion is being carried out. The generic name "AssignWithConversion"
doesn't make that obvious -- one had to infer it from the types.
The patch also removes two commented out lines from
editor/composer/nsComposerCommands.cpp, that appear to be related. They are
at top level, where they would never have compiled. They look like
leftovers from some previous change.
--HG--
extra : rebase_source : fb47bf450771c3c9ee3341dd14520f5da69ec4f5
nsIWidget::NotifyIME() should call only TextEventDispatcher::NotifyIME() if it's necessary. Then, TextEventDispatcher::NotifyIME() calls TextEventDispatcherListener::NotifyIME() if it's necessary. E.g., requests to IME are necessary only for TextInputProcessor or native IME handler because the composition is only owned by one of them. However, notifications are necessary for both of them since focused editor contents and its focus state are shared.
So, it doesn't need to call nsBaseWidget::NotifyIMEInternal() if all NotifyIMEInternal() implementations are moved to proper TextEventDispatcherListener::NotifyIME(). Currently, nsBaseWidget::NotifyIMEInternal() is implemented only by PuppetWidget. It sends notifications and requests to the parent process for native IME. Therefore, we can move NotifyIMEInternal() implementation to TextEventDispatcherListener::NotifyIME() which is implemented by PuppetWidget.
This patch moves PuppetWidget::NotifyIMEInternal() implementation to PuppetWidget::NotifyIME() of TextEventDispatcherListener class, not of nsIWidget and removes NotifyIMEInternal() completely.
With this change, handling order is changed. Old behavior is, TextEventDispatcher::NotifyIME() calls TextEventDispatcherListener::NotifyIME() before handling NOTIFY_IME_OF_FOCUS and then, nsBaseWidget::NotifyIME() sends the notification to the parent process. However, new behavior is, the notification is sent before TextEventDispatcher::NotifyIME() handles NOTIFY_IME_OF_FOCUS. Therefore, with new handling order, TextEventDispatcher can have IME notification requests after setting focus correctly. Additionally, TextEventDispatcher for PuppetWidget updates the notification requests at every event dispatch via TextEventDispatcher::BeginInputTransactionInternal() by the previous patch.
So, with those patches, IMEContentObserver can refer actual IME notification requests correctly even after we'll make focus notification to async message.
MozReview-Commit-ID: JwdQ68BjTXL
--HG--
extra : rebase_source : fbc7e311d83aab3b38fdd5c1b5c24d85458eb77b
In the parent process, every nsIWidget instance like nsWindow has TextEventDispatcher instance after dispatching a keyboard event or a composition event. Then, TextEventDispatcher manages whether there is composition and handles NotifyIME. However, PuppetWidget doesn't have it unless it synthesizes keyboard events or composition events for tests.
This causes PuppetWidget implementing nsIWidget::NotifyIME() with nsBaseWidget::NotifyIMEInternal() which is a virtual method only implemented by PuppetWidget. For consistent implementation around here, we should move NotifyIMEInternal() implementation to TextEventDispatcherListener::NotifyIME() which is called by TextEventDispatcher::NotifyIME(). Then, PuppetWidget can handle NotifyIME() easier.
This patch creates TextEventDispatcher::BeginInputTransactionFor() which takes pointer to a dispatching event and pointer to PuppetWidget. It emulates each corresponding event dispatcher method for managing composing state and begins input transaction for the dispatching event.
Unfortunately, this implementation is ugly due to duplicated code. However, this is enough for now. When we need to make TextEventDispatcher manage more states, we should add methods which are shared by both BeginInputTransactionFor() and event dispatcher method.
MozReview-Commit-ID: GeP028luZjR
--HG--
extra : rebase_source : ce71ce4d7ba52aeb12bff2c403c9a6df47ea3a11
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
If ContentCacheInParent::RequestIMEToCommitComposition() returns true after its TabParent has already sent eCompositionCommit(AsIs) event, ContentCacheInParent::OnEventNeedingAckHandled() will receive both eCompositionCommit(AsIs) and eCompositionCommitRequestHandled for a composition. Then, that causes making mPendingCompositionCount decreased twice. That causes the crash.
So, even if its TabParent already lost focus, it should return false after its TabParent sent eCompositionCommit(AsIs).
MozReview-Commit-ID: 6OylQtc8kgC
--HG--
extra : rebase_source : 9d8f2ab2b25f129ddbca75fcc8fb4bc7c3a96e56
Use the regular XPCOM queue for those tasks because the priority queue
should only be used for input and other timing-sensitive tasks.
MozReview-Commit-ID: 5px0s0PJYrV
The native binding code used `jni::AbstractCall` as the interface
between `ProxyNativeCall` and `DispatchToGeckoPriorityQueue`. However,
we already make use of `nsIRunnable` for dispatching to the XPCOM queue,
so we should just use `nsIRunnable` for the priority queue as well.
MozReview-Commit-ID: KmuNMZZkXX3
Don't crash when we encounter a selection exception when in Beta. Still
crash when in Nightly so we can investigate the source of the crash.
r=me for trivial patch.
MozReview-Commit-ID: HgmudX4VfWO
There is no side-effects by this commit because this macro definition is
not used in actual implementation.
--HG--
extra : amend_source : 6075bacf7c0e2c10dd66dcfda8e28f16786d58de
In the frontend we need to know if XUL buttons in the toolbar were
triggered by a touch event, so we're passing on the inputSource
in the command event.
MozReview-Commit-ID: DMvgZULk9hT
--HG--
extra : rebase_source : c455c8ec77e439bf02c1e3e8d34a36e1fb5e3bd0
`nsRange` registers mutation observers to adjust the range when content
changes. However, there are some cases where we adjust the start and/or
end offsets but don't notify selection listeners (i.e. we don't call
`nsRange::DoSetRange` to set the new range points, contrary to what the
comment above `nsRange::DoSetRange` says). This patch makes us call
`nsRange::DoSetRange` in those cases. The patch adds a testcase in
test_selectevents.html, and changes a few unexpected-pass cases in
test_composition_text_querycontent.xul that this patch fixed.
MozReview-Commit-ID: 73D8RYMS3MS
--HG--
extra : rebase_source : da0cc3073e4b8ad23c6f6eab42da5aa8b269cae9
When the start node is a non-container node (i.e. <br>), and the start
offset is 0, we should not include a newline character for the node. For
example, for this range,
> <br/>hello
> \___/
the start node/offset is (<br/>, 0) and end node/offset is ("hello", 1).
The calculated range offset should be 0, and the range length should be
2: 1 for the <br/> newline character plus 1 for "h".
The patch also ensures this behavior for pre-mode nsContentIterator, for
both start and end node adjustments. For start nodes, we include any
non-container nodes with offset 0 in the range. For end node, we exclude
any non-container nodes with offset 0 from the range.
MozReview-Commit-ID: Lt2tCLbapq7
--HG--
extra : rebase_source : 7d86b6cf04581f1cd71fa85f8c8586541b3a84e9
The fix for bug 1373079 neglected the detail of OpenThemeData
that it can return null if no match is found for the specified
class name. The set of matching class data sections varies with
the default and the classic theme, and the classic theme doesn't
have matches for a few of the values that we try to get. This
causes us to pass a null theme to subsequent functions, which of
course breaks the layout.
MozReview-Commit-ID: 5LaR0qZlOzd
--HG--
extra : rebase_source : ba97163e5dfdd7127d550be54524e93f12195ffb
Ideally, we definitely want APZ in remote popup browsers for the sake of
responsiveness. However, there are currently some serious painting and
checkerboarding issues that make APZ popups unsuitable for release
populations.
Once these issues are addressed, we should enable the preference by default.
But given the relative lack of testing, and the issues we've seen so far, we
should keep the preference so that we can disable it with a hotfix if further
issues arise.
MozReview-Commit-ID: GOZRdsmLNZR
--HG--
extra : rebase_source : ce0f2ca029d951a9c65ec1482e065b6695793133
SetParent removes the widget from the old parent widget and then sets its new one. We were incorrectly using the new parent widget when we needed the old one.
1. Pause the Exoplayer when navigating to another page and resume playback when navigating back.
2. Fix the OOM issue.
MozReview-Commit-ID: 5UGmBzpObsb
--HG--
extra : rebase_source : f8f268612687669e1b31881465600b02b3531c55
This avoids a fatal assertion for some key events when focus isn't on a text
input.
MozReview-Commit-ID: Hqr6LNW61Kn
--HG--
extra : rebase_source : adc954fc355044c91dc34e9e689a745da95e78c9
Most of the names passed to nsIStringBundle::{Get,Format}StringFromUTF8Name
have one of the two following forms:
- a 16-bit C string literal, which is then converted to an 8-bit string in
order for the lookup to occur;
- an 8-bit C string literal converted to a 16-bit string, which is then
converted back to an 8-bit string in order for the lookup to occur.
This patch introduces and uses alternative methods that can take an 8-bit C
string literal, which requires changing some signatures in other methods and
functions. It replaces all C++ uses of the old methods.
The patch also changes the existing {Get,Format}StringFromName() methods so
they take an AUTF8String argument for the name instead of a wstring, because
that's nicer for JS code.
Even though there is a method for C++ code and a different one for JS code,
|binaryname| is used so that the existing method names can be used for the
common case in both languages.
The change reduces the number of NS_ConvertUTF8toUTF16 and
NS_ConvertUTF16toUTF8 conversions while running Speedometer v2 from ~270,000 to
~160,000. (Most of these conversions involved the string
"deprecatedReferrerDirective" in nsCSPParser.cpp.)
--HG--
extra : rebase_source : 3bee57a501035f76a81230d95186f8c3f460ff8e
Defining the default draw target avoids the previous mix of cairo
and d2d layers, which would trigger an assertion when capturing
a page with the widget layers.
Testing for cache differences via assertions on try revealed that
we need to special-case buttons in our cache, since they can have
two different values for aSizeReq. Visual inspection of the code
reveals that this is the only aWidgetType value that has this
problem. I'm not sure how future-proof we want to try to be with
this. If anything else starts varying in this parameter then we
might unwittingly introduce caching problems, but I don't know
how likely that is.
MozReview-Commit-ID: 3kaJ01oJe3
--HG--
extra : rebase_source : 9a9c15f38eee7c59cd73e7fe42a0f581e0adeac5
See commit (1) for more detail about the bug.
This patch caches the expensive parts of GetMinimumWidgetSize,
which are when we call GetDC and ReleaseDC. The exits before this
cached section don't have their results cached partly because
they don't seem to show up in profiles, and partly because we
don't necessarily have a theme part at that point, which means
we would need to have a more complicated caching scheme directly
involving the aWidgetType.
MozReview-Commit-ID: 886N4tTHVVk
--HG--
extra : rebase_source : 31c4750088c26d140813419c63277a330472b84e
Both GetWidgetBorder and GetMinimumWidgetSize are showing up
in some profiles (see bug for more details.) This is the first
patch in a series of patches which cache the results of these
functions.
Because aWidgetType can map to multiple theme parts, in order to
cover as much as possible with our cache we decided to cache
based off of the theme class and the theme part, which are derived
from the aWidgetType and misc. other state. (Assumption: the
widget border and minimum widget size should not changed based on
the theme "state" (the value that accompanies the "part".))
The total cache size for these, if we use plain arrays, is 18KB.
We could reduce this by some amount by using a sparse dynamically
sized cache or by just using aWidgetType and discarding the
overloaded values, which are few. I don't have a great intuition
for how much we care about saving a few KB, or how much time this
could cause us to lose on L1 and L2 cache misses. Accordingly it
might be more optimal to go with something else, and I am open to
criticism/suggestions.
MozReview-Commit-ID: 4LG9BnaRG7l
--HG--
extra : rebase_source : 6d3ecf11e02a863f5528fb3ec2417eb1a246574c
James Willcox
Makoto Kato
peter chang
Wes Kocher
Eric Rahm
Farmer Tseng
Carsten "Tomcat" Book
Nicholas Nethercote
Bill McCloskey
Markus Stange
Michael Layzell
Sebastian Hengst
Yoshi Huang
Mason Chang
Milan Sreckovic
Chung-Sheng Fu
Masayuki Nakano
Stone Shih
Jim Chen
Ryan Hunt
Ryan VanderMeulen
Masatoshi Kimura
Martin Stransky
Brendan Dahl
Bob Owen
Eugen Sawin
Christoph Kerschbaumer
Manish Goregaokar
Karl Tomlinson
Jan Henning
sotaro
Chris Pearce
Ehsan Akhgari
Jonathan Watt
Alex Gaynor
Michael Smith
Botond Ballo
Tobias Schneider
Julian Seward
kevin
Bevis Tseng
Kartikaya Gupta
James Cheng
Sylvestre Ledru
Kentaro Hayashi
Andrew Osmond
Johann Hofmann
Dão Gottwald
Benjamin Smedberg
Haik Aftandilian
Doug Thayer
Samael Wang
Kris Maglione
David Parks
David Anderson
Blake Kaplan
Josh Aas