This patch replaces the usage of sNextTabParent pointer to store the next
PBrowser parent actor to be used by the next frame loader with the
following information:
* In the case where the content JS has requested a new tab, the ID of the
next TabParent will be stored on the <xul:browser> element.
* In the case where the content JS has requested a new window, the ID of
the next TabParent will be stored on the created nsXULWindow.
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
Previously, all `PushNotifier` methods checked the process type, and
either called `Notify*{Workers, Observers}` or sent an IPDL message.
The message handlers then called back in to `PushNotifier` from the
remote process.
This was clearer when we only sent worker event notifications to the
content process, and fired all observer notifications in the parent.
It became more complicated once we started notifying observers for all
subscriptions in both processes (bug 1266433). This makes it harder to
see omissions; for example, "push-subscription-modified" isn't
currently forwarded to the child, but "push-subscription-change" and
"push-message" are.
This patch moves the remoting code into `PushNotifier::Dispatch`, and
adds a base `PushDispatcher` class. Each notification type subclasses
this class and implements logic for sending messages and firing
observers and worker events. It's more code, but a bit easier to see
which methods are called where.
MozReview-Commit-ID: 7Q0eD7qXOrW
--HG--
extra : rebase_source : c69acb95a0cb5470cf1c804639971be41b976cc2
This is useful for writing tests that test particular optimizations,
such as that a particular operation doesn't cause restyles. It sits
next to similar counters for frames constructed and frames reflowed.
I also snuck in a preference for the less-expensive mPresContext over
the more expensive mFrame->PresContext() (which dereferences multiple
pointers).
(Originally written for work I planned to be part of bug 1189598.)
MozReview-Commit-ID: 8PN7nwLJG9r
Adds a new IPC message to the PBrowser protocol exposing
the number of tabs in the current window to the content
process. This allows the content process to reject window.resize*
calls in cases where there is more than one tab in the
window.
--HG--
extra : histedit_source : dfa6b7b71882a1583cbbe90c2a7327cb212ed15d
Several code paths try to ask the principal if it's in a browser element, but
the principal now only knows about *isolated* browser elements. All such code
paths are currently unused on desktop. The frame loader now asserts that
isolation remains enabled for cases where apps are used.
MozReview-Commit-ID: 775DZecc35t
Renames existing nsFrameLoader::OwnerIsBrowser* methods to add "Moz" prefix for
clarity.
Adds nsFrameLoader::OwnerIsIsolatedMozBrowserFrame which checks the noisolation
attribute of mozbrowser frames, if present.
This is used to set isolation in nsFrameLoader::GetNewTabContext only when true.
MozReview-Commit-ID: Dz02xBoKh1P
Ehsan Akhgari
Carsten "Tomcat" Book
Masayuki Nakano
Randall Barker
Daisuke Akatsuka
Daisuke Akatsuka
Tom Tung
Thomas Nguyen
Gabor Krizsanits
Michael Layzell
Boris Zbarsky
Mike Conley
Cameron McCormack
Iris Hsiao
Andrea Marchesini
Joel Maher
Blake Kaplan
Andrew Sutherland
Matt Woodrow
J. Ryan Stinnett
Phil Ringnalda
Sebastian Hengst
Catalin Badea
Kaku Kuo
Ho-Pang Hsu
Stone Shih
Sotaro Ikeda
Christoph Kerschbaumer
George Wright
Kan-Ru Chen
Samael Wang
Yoshi Huang
Julian Descottes
James Willcox
Wes Kocher
Tooru Fujisawa
Bill McCloskey
Thomas Wisniewski
Jean-Yves Avenard
Kaku Kuo
Timothy Nikkel
Kartikaya Gupta
Edouard Oger
Jimmy Wang
James Andreou
David Zbarsky
Matthew Gregan
Tom Tromey
Jan Henning
Fabrice Desré
Paul Roberts
Makoto Kato
Chih-Yi Leu
SUN Haitao
Kit Cambridge
Frederik Braun
L. David Baron
Alastor Wu
Jonathan Watt
Kris Maglione
Haik Aftandilian
Josh Matthews
John Dai
Christoph Kerschbaumer
Abdelrhman Ahmed
Aidin Gharibnavaz
Deepthi Venkitaramanan
Jeffrey Tran
Ciro S. Costa
Kyle Huey