Closed Bug 1249035 Opened 10 years ago Closed 10 years ago

WebExtensions: No reset to default_icon on reload

Categories

(WebExtensions :: Untriaged, defect, P4)

defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: nico.schloemer, Unassigned)

Details

(Keywords: testcase-wanted, Whiteboard: triaged)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36 Steps to reproduce: I'm in the process of porting a Web Extension from Chrome over to FF. The manifest contains ``` "browser_action": { "default_icon": { "19": "images/icon-gray-19.png", "38": "images/icon-gray-38.png" } }, ``` and I noticed that the default_icon is not assigned when navigating away from a page. Expected results: Chrome does reset to default_icon whenever you open a new tab or if you reload an existing tab.
Component: Untriaged → WebExtensions
Product: Firefox → Toolkit
Can you attach a testcase add-on?
Flags: needinfo?(nico.schloemer)
Keywords: testcase-wanted
Check out [1,2]. Navigate to e.g., [3], observe the icon changing from gray to blue. Navigate in the same tab to another page, e.g., [4]. The default_icon is not updated. [1] https://addons.mozilla.org/en-US/developers/addon/paperhive/ [2] https://github.com/paperhive/paperhive-web-extension [3] http://arxiv.org/abs/1208.0264 [4] https://www.google.com/
Flags: needinfo?(nico.schloemer)
That add-on is too complicated to be a useful testcase. We follow the documented behavior of Chrome, which is to persist tab-specific browserAction changes for the life of the tab, and to persist pageAction changes until the page navigates. If Chrome does not actually follow this behavior, a testcase that demonstrates this would be useful.
Priority: -- → P4
Whiteboard: triaged
Thanks for the update. Not messing with the brwoserAction for the lifetime of the tab does actually sound like the right thing to do. I've adapted the extension accordingly.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.