For testing IMEContentObserver, text change, selection change and position change notifications should be exposed to JS with nsITextInputProcessorNotification.
MozReview-Commit-ID: 3PUhKXRwnAn
--HG--
extra : rebase_source : fce7a73683a2d4811070453629ef48d3ad15c8c8
This version of the Dynamic Toolbar moves the animation of the toolbar
from the Android UI thread to the compositor thread. All animation for
showing and hiding the toolbar are done with the compositor and a static
snapshot of the real toolbar.
MozReview-Commit-ID: BCe8zpbkWQt
In this patch, we implement nsIDOMWindowUtils::GetUnanimatedComputedStyle
which returns computed value of given CSS property without animation rule. This
method is used from the DevTools animation inspector to fill in keyframe values
when the property value is null (indicating that the underlying/base value is
being used).
In order to implement this, we extend nsComputedDOMStyle constructor to fetch
the computed style minus animation style (i.e. the base style). This is somewhat
complicated by the fact that for discrete animation.
StyleAnimationValue::ExtractComputedValue may return ‘unset’, ‘initial’ or
‘inherit’. For example, if the author uses the 'unset' 'initial' or 'inherit'
keyword for a discrete property (e.g. 'align-content’), ExtractComputedValue
returns the keywords as-is. Furthermore, if the user does not set any specific
keyword, ExtractComputedValue returns ‘unset’. We use this new
nsComputedDOMStyle mechanism to resolve these keywords into a valid keyword for
computed style in the same way as other properties (e.g. ‘opacity’).
MozReview-Commit-ID: HffJ9SCDf2k
--HG--
extra : rebase_source : 64df3850b862dada5f8e0767d47dc478d454ba31
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
This changes the `relatedBrowser` property which held a <xul:browser> to the
more explicit `sameProcessAsFrameLoader` which takes an nsIFrameLoader.
This clarifies the purpose of the property and also (by switching to the frame
loader) makes it easier to set in some contexts.
MozReview-Commit-ID: LnEvSP8zkto
--HG--
extra : rebase_source : f9f4c07995ef39f1ccd5042e9ae3df37879423b6
For simplicity, this test is being added to test_classifier.html which
already has all of the infrastructure necessary for setting up a test
domain as a tracking domain.
This adds a single flag, SWAP_KEEP_PERMANENT_KEY, which tells the
browser that when it performs the swap, the permanent key should stick
with the browser, rather than following the frameLoader.
This patch also adds the implementation of tabbrowser.swapBrowsers,
which was previously absent, despite being referenced.
MozReview-Commit-ID: CLwJYzpY8Pp
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
I'm not 100% sure that I'm being very consistent in my handling of
mFocusedValue, but since that's not used for file inputs, I don't think it
matters much...
A bigger problem is if people start using this caller type for things other than
file inputs.
The only nsGenericHTMLElement::GetEditor callers are
HTMLInputElement::GetEditor/HTMLTextareaElement::GetEditor (the XPCOM-y
versions), which are only called from C++ and only from two places: a11y code,
which forces itself to look like system, and typeaheadfind, which would break
badly if it could not get an editor. So that security check simply shouldn't
exist.
The script API doesn't call down into here _and_ is [ChromeOnly] in the webidl
already.
Add swapBrowsers() for frameloader or other platform components to swap frameloaders
and <xul:browser> listeners.
Add closeBrowser() for chrome process top-level frameloader to correctly remove /
close a tab.
MozReview-Commit-ID: KzM0xL8goUN
--HG--
extra : rebase_source : 87fe1a611b8d5094b0cdc09d503e6793799bab03
nsIBrowser looks not strictly related to IPC but more like an XPCOM
representation of <xul:browser>. Since even nsIRemoteBrowser which is
for <xul:remote-browser> lives in dom/interfaces, moving nsIBrowser
to dom/interfaces makes more sense.
MozReview-Commit-ID: 5DnWaBrkzaJ
--HG--
rename : dom/ipc/nsIBrowser.idl => dom/interfaces/base/nsIBrowser.idl
extra : rebase_source : 68fed039fda73b60683b3297d14b2bad78e07483
As it turns out, the workaround used to detect "not activated" service worker registrations works only
in e10s pages. In non e10s, service worker registrations are returned even if they are not in activated
state. Here we add the currently associated worker to the registration info, which will be used
to determine if the service worker is activated by about debugging.
MozReview-Commit-ID: ImeZcXQdBtO
--HG--
extra : rebase_source : f7e023708f8954b978b189025fd0b06c587d6a8e
Instead of "not visible", "approximately visible", and "visible" (in display port) we now have "approximately not visible", and "approximately visible" which includes "visible".
When swapping content from <iframe mozbrowser> to <xul:browser>, we now stop the
frame scripts that implement the content side of the browser API since they are
no longer needed and can cause issues if they remain active.
MozReview-Commit-ID: JrecxA4MI93
--HG--
extra : rebase_source : cc68b975c7d82035410a647ff66eab130055ed04
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
The mobile session store saves the current document resolution in order to restore the previous zoom level when restoring a page. If the display width has changed since the session data was captured (e.g. because the device was rotated), the resolution might have to be scaled appropriately.
Currently, the session store does this scaling by itself by comparing the stored and current window widths, however this implementation is slightly simplified and doesn't cover all use cases, which means some pages can be restored at a wrong zoom level after rotation. To correctly cover all cases, the session store would have to compare viewport widths, too.
Because the MobileViewportManager doesn't wait for the session store to set the restore resolution, the latter has to call setRestoreResolution() as early as possible in order to guarantee that the restore resolution is set before the first paint of the document. Therefore the session store currently calls this after receiving a LocationChange notification. However at that time, the correct viewport for the current document is not yet available, which means the resolution cannot be recalculated by the session store at that point.
Therefore, this patch changes the approach taken and lets the MVM handle all resolution calculations instead. The session store now simply passes the stored previous display dimensions along with the previous document resolution to the MVM, which can then compare them to the current display and viewport widths and scale the resolution appropriately before using it during first paint.
MozReview-Commit-ID: IGxWw87yftK
--HG--
extra : transplant_source : e%8D%BD%26%D2%C3%8E5%E3%2B%C0t%BA%DB%C1%BBs%3F%13%1F
The intention is for the session store to record the current window size and then pass it to the MobileViewportManager for restoring, so the latter can correctly scale the stored resolution if the display width has since changed. However currently all window dimensions available from the JS side are measured in CSS pixels rounded to integers. Transforming those values back into display pixels by multiplying them with "window.devicePixelRatio" (or accessing window.gScreenWidth/Height, which does the same thing internally) unfortunately introduces some rounding errors.
Therefore this patch introduces a new helper method in DOMWindowUtils which allows to access the content window width as measured in device pixels from the JS side, too.
MozReview-Commit-ID: FGNQlXhkgrU
--HG--
extra : transplant_source : %8B%90G%5C%C7%87%B8%8F%0D%EA%3B%FF%3AU%D5%07%81%E7%7Cq
To test eQueryCharRectArray, I would like to add it to nsIDOMWindowUtils. Also this require unit test and will require external keyboard support on Android
Masayiki asks me more review to smaug this due IDL change.
MozReview-Commit-ID: 24lvQxXBnRX
--HG--
extra : rebase_source : 30788f550a465dc1ee058bf71d56656a89e364c2
extra : histedit_source : 2d2a2d4309b1fde6416408fe0e0d6b0f313898fb
Native IME handler may want to query content relative to start of selection (or composition if there is it). Additionally, in e10s mode, insertion point in actual content may be different from the cache in parent. Therefore, in some cases, it does make sense to query content with offset relative to start of selection or composition.
This patch implements it simply and only in non-e10s mode.
Additionally, this fixes a bug of nsQueryContentEventResult::GetOffset() which hasn't been accepted its calls even if the event message is valid (eQueryTextContent, eQueryTextRect and eQueryCaretRect).
MozReview-Commit-ID: 34I7vyTUAgO
--HG--
extra : rebase_source : d79ba0dc3e002f7691495ee1ff8bdb3854d8f6fe
