Add a Send to Device subview to the page action panel. When the page isn't
sendable, disable the Send to Device menu item. When the user doesn't have any
devices, show a menu item that opens the Firefox Account preferences pane.
Generalize gSync.populateSendTabToDevicesMenu() so that it can be used to
populate any kind of container, not only a menupopup with menuitems.
Add an SVG that shows a phone and an SVG that shows a desktop.
MozReview-Commit-ID: EZQKAEAr08q
The height of the "panelmultiview" binding is now determined by the stack layout code, and doesn't have to be calculated manually via JavaScript anymore. This allows the removal of mutation and overflow observers, and reduces the number of synchronous layouts being made.
There is still a workaround included for wrapping blocks not being taken into account in height calculations.
MozReview-Commit-ID: 9rrPU5O5hUx
Since we now have a store of notifications that is global across
all windows, it no longer makes sense to consume the API from
within browser.js. This patch moves the browser.js logic out into
a jsm file that is wired up through nsBrowserGlue, such that it
will be lazily instantiated on the first update event it would
receive[1].
We decided to move this into toolkit, as this piece of the
system is fairly generic and shouldn't differ between
applications.
[1]: There is a change to nsBrowserGlue to use "global[module]"
instead of this[module]. This mirrors the code for all the other
types of notifications, and I suspect it was just a latent bug,
since the original diff that includes this line makes no use of
it.
MozReview-Commit-ID: 8EQdM9BOpgl
This prevents short-lived processes when we are not at the maximum normal content process count and the new window's first tab is not going to load in that remote type.
This change means that any related http pages driven through content (window.open, links, etc.) will continue to be loaded in the file content process.
Same-origin loads via the UI will also remain in the file content process.
Cross-origin loads via the UI will cause a process switch.
History navigation will stay in the process, if it was originally loaded in that process.
The "blocked" attribute is too general to indicate the real usage, so rename it
to "activemedia-blocked".
This attribute indicates that whether the tab has blocked the autoplay media.
MozReview-Commit-ID: EAmq6OuBYjq
This patch adds a visual UX cue to visually distinguish the user agent
sessions that are under remote control from those used for normal
browsing sessions. The new hue helps the user identify windows that
are under automation.
browser/base/content/browser.js will now query Marionette to find out if
the remote protocol is running when starting a new <xul:browser>.
The remote-control system notification will also be sent when the
Marionette remote protocol is running, activating any already opened
<xul:browser>s. The message is sent from testing/marionette/server.js.
MozReview-Commit-ID: AsjGmLL1Rl1
Calling HTMLMediaElement.canPlayType() on the main thread will cause
us to do disk I/O to load system decoding libraries, so we shouldn't
do it on the main thread, let alone on the parent process' main thread.
I moved the telemetry into an idle service observer off main thread
into Gecko in the previous patch.
MozReview-Commit-ID: CH6LNNLzreJ
__define{Getter,Setter}__ are deprecated, and are not defined on
NonSyntacticVariablesObjects, so these calls get in the way of sharing
globals between different .jsms. Probably only the DownloadUtils.jsm
change is really needed for that.
configurable and enumerable are both set to true to match the existing
behavior. If enumerable is set to false, then tests fail, because some
of the getters overwrite the getter with a regular property.
MozReview-Commit-ID: 1OZF45fIAQ
If there is an update available but the user can't apply it, we
publish a notification on the update-available topic with the
status "cant-apply". This was previously being ignored by
browser.js. This should fix the bug in question on Windows 10.
MozReview-Commit-ID: 1twRvYEXbiT
This patch creates a new print preview browser to host the simplified cloned-document
when Simplify Page option is used on preview. Also, this patch keeps track of what browser
should be presented, based on whether the 'Simplify page' checkbox is checked.
MozReview-Commit-ID: FZSRUyC49Wk
This patch creates a new print preview browser to host the simplified cloned-document
when Simplify Page option is used on preview. Also, this patch keeps track of what browser
should be presented, based on whether the 'Simplify page' checkbox is checked.
MozReview-Commit-ID: FZSRUyC49Wk
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.
* Track window states: active, fullscreen and tabsintitlebar for each window
* Use toolbar.id and window state to store and retrieve values from cache
* Note: As each window has its own ToolbarIconColor object, the cache is not currently shared across windows
* inferFromText callers pass in a reason and associated value, which is used to update the state we track, and potentially clear out the cache
* Create new windows test directory for browser-window-specific tests like this
* Test for the ToolbarIconColor changes to avoid sync style flushes when windows activate/deactivate
MozReview-Commit-ID: JDJ3RtL4Lge
This patch creates a new print preview browser to host the simplified cloned-document
when Simplify Page option is used on preview. Also, this patch keeps track of what browser
should be presented, based on whether the 'Simplify page' checkbox is checked.
MozReview-Commit-ID: 77pLXhdbpPp
