Implement ShowPageAction for declarativeContent API
Categories
(WebExtensions :: General, enhancement, P5)
Tracking
(Not tracked)
People
(Reporter: mconca, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 2 obsolete files)
(deleted),
text/x-phabricator-request
|
Details |
Reporter | ||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Require extension API functions that start with a capital to be called
with "new", since these look like constructors.
The internal API implementation is not called with "new", because the
resulting class instance would belong to a privileged context and be
inaccessible to (unprivileged) extension code anyway.
It is the responsibility of these "constructor" implementations to
create and return an object that is cloned into the extension contexts's
scope.
Comment 2•6 years ago
|
||
-
Move
isShown
call fromhandleLocationChange
toupdateButton
. -
Move tab / tabData at the top of
updateButton
into the
requestAnimationFrame
call to avoid potentially updating the page
action with data from an inactive tab shortly after a tab switch. -
Remove
showMatches
/hideMatches
from TabContext, as they are
not specific to tabs. -
Remove unnecessary guard on
browserPageAction
assignment.
Depends on D25589
Comment 3•6 years ago
|
||
See the comment at the top of ext-declarativeContent.js for an overview.
This is an implementation of the rule registry and evaluation engine of
the declarativeContent API. It is kept simple for now, supporting only
URL-based conditions and showing page actions. The logic is designed to
support content-based conditions such as matching by CSS selectors. The
actual interaction with content is part of the next patch.
The next patches will add the following functionality:
- Supporting content-based conditions (i.e. match by CSS selector).
- More actions (SetIcon, IgnoreRules)
Potential future improvements:
-
The rule engine logic can be part of toolkit/, but is in browser/ for
now to minimize the amount of changes. If the approach of this patch
looks right, it may make sense to add a separate patch that performs
the necessary refactoring of mobile code and move the implementation
to toolkit/. -
StartupCache is currently the primary storage for rules, and a
runtime.onInstalled
event is forged when the cache disappears,
e.g. when an add-on is disabled and re-enabled.
This artificial event could be removed if the rules are stored
elsewhere besides StartupCache.
Depends on D25590
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 4•2 years ago
|
||
The following patch is waiting for review from an inactive reviewer:
ID | Title | Author | Reviewer Status |
---|---|---|---|
D25591 | Bug 1465995 - Implement declarativeContent.ShowPageAction | robwu | rpl: Resigned from review |
zombie: Resigned from review |
:robwu, could you please find another reviewer or abandon the patch if it is no longer relevant?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Description
•