When the New Tab page is opened, the browser object that is passed into the isArticleChangeListener
is not a valid browser from the perspective of tabbrowser.xml, so it is not able to find it in its
_tabForBrowser map. This causes undefined to be passed into tabManager.getWrapper(), which causes
the error.
This patch fixes this by not calling tabManager.getWrapper(), and subsequently firing the onUpdate
event, if the return value from gBrowser.getTabForBrowser() is undefined. Testing shows that that
is only the case when the New Tab page is opened, and that page is not, and is unlikely to be
readerable any time in the foreseeable future (confirmed on IRC), so ignoring this case in the
listener is acceptable.
MozReview-Commit-ID: D9LQRrPmCoU
--HG--
extra : rebase_source : da5c074c2e59babb5385d24a4f768aa4b7ae8997
It is helpful to have a slot which never has a token, so that the
absense of a token can be asserted in unit tests.
Add a third token that is always empty, and update a number of unit
tests to check for it.
MozReview-Commit-ID: 4apvRRhZJus
--HG--
extra : rebase_source : cd3bb819bcf66c769f36a428ed26ea8fa6c68a26
This applies the following changes:
- store a weak reference to the browser element in the WebNavigation.jsm Manager's map
of pending CreatedNavigationTarget messages
- when a CreatedNavigationTarget message is received from a sourceTab
for a created window that is not currently tracked in the map
(e.g. it has been immediately closed), the message received from the sourceTab
is not saved in the map of the pending CreatedNavigationTarget (and a message
is logged in the console to make easier to investigate issues related to discarded
CreatedNavigationTarget events).
- adds an additional assertion to the related test case to ensure that no CreatedNavigationTarget
message is still pending in the WebNavigation/jsm's Manager.
MozReview-Commit-ID: FijQ8IqiY8L
--HG--
extra : rebase_source : cd3c072301a1eb24de368c655a96891dd1287c7b
This changes fixes the regression introduced by Bug 1355120 and adds a new
test case which contains a browserAction popup which open and immediately
close a new window and ensure that the received onCreatedNavigationTarget
is the expected one.
MozReview-Commit-ID: JIcVCpBTpxj
--HG--
extra : rebase_source : 37a7db29fa91d0e3f0593f7d5d996ccd3fba719d
It is helpful to have a slot which never has a token, so that the
absense of a token can be asserted in unit tests.
Add a third token that is always empty, and update a number of unit
tests to check for it.
MozReview-Commit-ID: 4apvRRhZJus
--HG--
extra : rebase_source : 13bfac22fcf4dfbdbcbff25254785e53cbd25920
This option works in Chrome and is documented to work in Firefox but seems
to have never been implemented.
MozReview-Commit-ID: KOu8TRaCCzL
--HG--
extra : rebase_source : 98605a64c12102e5c09acfd5bfef410cb75d5ba0
I had to add a mochitest because PlacesUtils.history.insertMany cannot create hidden redirects.
I also added a support for the "reload" transition while I am here.
MozReview-Commit-ID: ECQp6pW2r8v
--HG--
extra : rebase_source : d4456d32a57cdadec8ca383a2b09dee29e20b10f
This allows a bunch of additional stuff to be removed: ContextStateTracker,
ContextStateTrackerOGL, and GPUMarkerPayload.
--HG--
extra : rebase_source : 879045a9f9ac31ca0beb596964c6c3ef30283a53
Because it just doesn't control any behaviour within the profiler, and it just
duplicates gfxPrefs::LayersDumpTexture().
With this gone, PROFILER_FEATURE_ACTIVE can also be removed.
--HG--
extra : rebase_source : d6718894b8a9332cf73729ea6b7bd2de348817bd
In the end the webextensions tests that test devtools should be able to load devtools
apis in the same way as devtools tests. This allows to remove the gDevTools getter on
the devtools shim, which makes the paths that can potentially initialize devtools easier
to predict.
MozReview-Commit-ID: AHokH12ygKI
--HG--
extra : rebase_source : 9166f477e2d38351e836aa14c53a420bd9cbddf7
This applies the following changes:
- store a weak reference to the browser element in the WebNavigation.jsm Manager's map
of pending CreatedNavigationTarget messages
- when a CreatedNavigationTarget message is received from a sourceTab
for a created window that is not currently tracked in the map
(e.g. it has been immediately closed), the message received from the sourceTab
is not saved in the map of the pending CreatedNavigationTarget (and a message
is logged in the console to make easier to investigate issues related to discarded
CreatedNavigationTarget events).
- adds an additional assertion to the related test case to ensure that no CreatedNavigationTarget
message is still pending in the WebNavigation/jsm's Manager.
MozReview-Commit-ID: FijQ8IqiY8L
--HG--
extra : rebase_source : 20e5c27ba18f7f05f9076db19091f1c1153a6c39
This changes fixes the regression introduced by Bug 1355120 and adds a new
test case which contains a browserAction popup which open and immediately
close a new window and ensure that the received onCreatedNavigationTarget
is the expected one.
MozReview-Commit-ID: JIcVCpBTpxj
--HG--
extra : rebase_source : 0966eba7c752068522400b032a8018b96e9dcda9
All of the information needed for an extension to watch for tabs moving in and out
of reader mode is already available in the onUpdated event. This adds some asserts
to the existing test to check that this information is accurate.
MozReview-Commit-ID: 7OkR933MUPl
--HG--
extra : rebase_source : cf7a6bae5b7a4b6678b7fb1cb19027fa0ab97d71
Setting a max-height caused the '_handleDOMChange' method in ext-browser-content.js
to consistently lie about the scrollHeight, since it was never allowed to grow
beyond the maxHeight - even when the document needs to be larger to fit its contents.
We don't need this aggressiveness in Photon panels anyway, so that makes it
doubly safe to remove this code.
MozReview-Commit-ID: HJVMXXHS4By
--HG--
extra : rebase_source : 19cc957619afdd90d04fea0307b6323b33293841
Currently if there is no default icon at the specified size, the default icon
falls back to the light text icon at that size. This is wrong in two ways:
First, the default theme uses dark text, so it should fallback to the dark icon
Secondly, authors expect the unsized default_icon to be used if specified
This patch fixes both of these issues, so that the default icon first falls back
to the unsized default_icon, and then only if that is not specified falls back
to the dark icon
MozReview-Commit-ID: C3RRTKhYq6r
--HG--
extra : rebase_source : dc10f5c65c763412edbe467bb75aeb4fbcd32ffc
This WebExtensions API allows to install, remove, and query installed
PKCS#11 modules as well as to query the the status of available PKCS#11
"slots" for a given module.
Reuses the native application manifests from the "Native Messaging" API,
but using the "pkcs11" type rather than the "stdio" type.
All calls expect an application name, which is not the PKCS#11 friendly
name (the "description" field in the manifest file is used for that) but
instead the application name in the manifest file.
MozReview-Commit-ID: 8dHr5QfEaXv
--HG--
extra : rebase_source : 196ff66a8987be1b21463b725a2e207396e5eb0a
This WebExtensions API allows to install, remove, and query installed
PKCS#11 modules as well as to query the the status of available PKCS#11
"slots" for a given module.
Reuses the native application manifests from the "Native Messaging" API,
but using the "pkcs11" type rather than the "stdio" type. Update the
code for the Native Messaging API to ignore any manifests for the
"pkcs11" type.
All calls expect an application name, which is not the PKCS#11 friendly
name (the "description" field in the manifest file is used for that) but
instead the application name in the manifest file.
MozReview-Commit-ID: 8dHr5QfEaXv
--HG--
extra : rebase_source : 00cc9c6d8433460c93f9c579f1696e4e17d6d3a0
* Harden the new `hideAllViewsExcept()` to not do erroneous things if called when
the binding is already gone.
* Generalize things into `hideAllViewsExcept(thisOne)`:
- Clear `_viewShowing` in there and do the descriptionHeightWorkaround thing
in there too,
- For Photon panels, do all the 'current' attribute setting in there. To show
a panel during transition, I introduced the 'in-transition' attribute.
* I had to make sure not to over-eagerly dispatch 'ViewShowing' events, because
that confuses some,
* Move the temporary panel handling, which contains an ephemeral panelmultiview
instance, internally. This cleans up the hacky, duplicate PanelUI.js code nicely.
* Keep a local copy of `_transitionDetails` to ensure it's still there after transition,
* Harden `_cleanupTransitionPhase()` to only clear the phase that belongs to a
specific transition, _if_ that's passed in as an argument. This resolves any
potential raciness that might occur when `showSubView()` is called again mid-transition.
* Skip the UITour element visibility check when it's inside a panelview, because
too many things need to happen and that check is too simple to be useful in
that case.
MozReview-Commit-ID: 5HpJKs1Ny5j
--HG--
extra : rebase_source : b810e1de2dbd75932a42d68e751fdaecd9fee69a
This adds two properties to the Tab object:
- isArticle indicates whether the document in the tab is likely able to be
rendered in reader mode.
- isInReaderMode indicates if the document in the tab is being rendered in
reader mode.
It also adds a toggleReaderMode() which toggles a tab into and out of reader mode.
There is also a new case in which tabs.onUpdated will fire. When the isArticle
status of a tab changes, an onUpdated event will fire with data {isArticle: boolean}.
MozReview-Commit-ID: AaAQ0V5qm2Z
--HG--
extra : rebase_source : f9cbed6dff56781ecd86281cb46f23f0ec8aecf6
This adds two properties to the Tab object:
- isArticle indicates whether the document in the tab is likely able to be
rendered in reader mode.
- isInReaderMode indicates if the document in the tab is being rendered in
reader mode.
It also adds a toggleReaderMode() which toggles a tab into and out of reader mode.
There is also a new case in which tabs.onUpdated will fire. When the isArticle
status of a tab changes, an onUpdated event will fire with data {isArticle: boolean}.
MozReview-Commit-ID: AaAQ0V5qm2Z
--HG--
extra : rebase_source : 579fccb76358dc0d333409ed81669cf45576e67f
We weren't removing the 'open' attribute from the anchor if the transition didn't complete.
This patch fixes this by moving the addition of 'open' into _transitionViews, and its removal into
_cleanupTransitionPhase.
MozReview-Commit-ID: TS0CcwsHVN
--HG--
extra : rebase_source : 1bdace324f22ee95002024fe68b572a16dd25aac
If the back button is used to navigate a tab backwards in its history, and then the tab is closed,
the current implementation of sessions.getRecentlyClosed does not take this into account and
just uses the last item in the tab history for the values returned for the tab. This patch fixes
this by using the values for the current position of the tab in its history.
MozReview-Commit-ID: LcgtA5FqVWi
--HG--
extra : rebase_source : 3b8cd840fd30305471feec643f77d57378bd40d7
This patch ensures that the devtools panel browser elements are associated to
the same TabGroup of the other extension pages from the same extension.
MozReview-Commit-ID: 40TSPqGfTnz
--HG--
extra : rebase_source : 93c429c5a3277407da648e3efa03717b4bd22fbd
The bug was failing because we were calling the server but the connection was already closed.
In order to prevent such things, we check the number of nodes of the tree, and if it has only
one, then we wait on a mutation that will ensure that server calls are done.
MozReview-Commit-ID: 7kHAkYs2I4K
--HG--
extra : rebase_source : 0204960d4ea3cca8bd9614908a730a0d4d6b4e69
Currently tabs.onActivated (for the tab that becomes active after a tab is removed) fires before
tabs.onRemoved (for the tab that was removed). This is neither the order in which Chrome fires
these events, nor is it the order in which the internal TabSelect and TabClose happen in Firefox.
This bug fixes this so tabs.onActivated fires *after* tabs.onRemoved.
Note that this does introduce an issue in in-process mode, where window.close() will not
trigger a tabs.onRemoved event for the window, but Kris says "Meh" about that.
MozReview-Commit-ID: CrFR3jqL2u5
--HG--
extra : rebase_source : 5cc3d2a138bf812d13779e8ca1188b89ddbcdcc1
This adds a loadReplace option into the updateOptions object for tabs.update()
which, when set to true, will cause the loading of the new URL to replace the
current URL in the tab's history.
MozReview-Commit-ID: KZTuEl7cgb0
--HG--
extra : rebase_source : 24f006fe197f56b3102cb00e226d53036b9ba93b
This updates the browserSettings API to report the current value of the home page and the new tab page regardless of whether they are currently overridden by an extension.
MozReview-Commit-ID: 3usY3F4oIxl
--HG--
extra : rebase_source : f8a04b4d7e70db7133c664d60cd46f8b4cd5471f
This adds support for separators to the bookmarks API. Separators can now be created
and will be returned by any method that returns BookmarkTreeNodes. They will also be
included in data for the onCreated and onRemoved events.
BookmarkTreeNodes will now contain a `type` property which will be one of bookmark,
folder or separator. When creating a bookmark object, one can specify the type, or one
can rely on the Chrome-compatible behaviour which treats any bookmarks without a URL
as a folder. To create a separator one must specify a type as part of the CreateDetails
object.
MozReview-Commit-ID: BoyGgx8lMAZ
--HG--
extra : rebase_source : 95a06fe81d21d660aeecbd86b71ca6bbcd66eb10
This introduces browser.browserSettings.homepageOverride and browser.browserSettings.newTabPageOverride
which will return the values of the overridden home page and the overridden new tab page.
These browserSettings are read-only.
MozReview-Commit-ID: A9vJP2QIaoA
--HG--
rename : browser/components/extensions/test/browser/browser_ext_url_overrides_home.js => browser/components/extensions/test/browser/browser_ext_chrome_settings_overrides_home.js
extra : rebase_source : 7c3fc91a5ca489b909a8b60d5b4a882180a0276e
Provides access to the browser's internal Find APIs. Can search,
get range data and rect data on found results, and highlight results.
--HG--
extra : amend_source : dfa2b36794543378db58e411ca4e317a64921831
