Closed Bug 1410749 Opened 7 years ago Closed 5 years ago

Addons not working for the first tab after application start


(WebExtensions :: Android, defect, P3)

56 Branch


(fennec+, firefox57 wontfix, firefox58 wontfix, firefox68 fixed)

Tracking Status
fennec + ---
firefox57 --- wontfix
firefox58 --- wontfix
firefox68 --- fixed


(Reporter: fqyuqeji, Assigned: JanH)




(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170921064520

Steps to reproduce:

Setup: Android 5.1 (CyanogenMod), Fennec 56 (from F-Droid)

Actual results:

When I open Firefox for Android (after closing it via. menu > close or just let it close by Android), addons will have no effect for the initial tab (and every subsequent website I visit in that first tab). Only after I opened a second tab, addons start to show an effect (for that second tab and every new tab I open, but still not for the first tab).

It's the case for multiple, independently developed addons. (All are using WebExtentions and are continuously updated. Example: uBlock Origin)

Expected results:

Obvious. Addons should work immediately.
Correction: Some addons actually do have some effect, but not everything works.

For example, uBlock Origin still seems to apply network filters, but no cosmetic filters. Another addon, "usi (User|Unified Script Injector)" does not apply any scripts installed. The addons are visible in the menu though, but for uBlock, no counter is displayed. (As above, I'm talking of the first tab after application startup)

Very strange. I don't think it's an issue of the addons itself because both addons do not work correctly, both jointly and independently from each other (i.e. only one of those is installed).
We already had some problems because the Webextensions implementation didn't properly deal with the fact that on Fennec, tab IDs start from 0 (bug 1384964), so I wonder if this is another instance of this?

Can you test again with a current Nightly build [1] to see if the issue still persists?

[1] Either from the Play Store or else from
Flags: needinfo?(fqyuqeji) 	43M 	23-Oct-2017 11:01

is still affected.

I tried with a new profile, and as a minimal use case, I just installed uBlock Origin. Same behavior applies.
Flags: needinfo?(fqyuqeji)
tracking-fennec: --- → ?
Component: General → WebExtensions: Android
Ever confirmed: true
OS: Unspecified → Android
Product: Firefox for Android → Toolkit
Hardware: Unspecified → All
Closed: 7 years ago
Resolution: --- → DUPLICATE
@Andrew Swan: I don't see how this is related. This bug seems to be about the very first website only. But I am reporting this: "addons will have no effect for the initial tab (and every subsequent website I visit in that first tab)." Even after 10 hours of webbrowsing, if I am still in the initial tab, addons will not work correctly.
Flags: needinfo?(aswan)
Resolution: DUPLICATE → ---
This issue was reported on my issue tracker a few days ago:

Of interest, this is what I found so far:

Quoting myself:

> The issue does seem to be this code at line 459 of
> resource://modules/ExtensionChild.jsm:
> let recipient = Object.assign({}, sender);   
> if ( {
>     recipient.tabId =;      
>     delete;                    
> }
> I observe that the tab property is absent when the issue occur, and
> not absent when the issue does not occur. When tab property is absent,
> uBO's content scripts seem to be unable to receive messages from
> uBO's main process.
tracking-fennec: ? → +
Meanwhile, addon developers start to implement their own workarounds for this. Just that you know when you want to reproduce this issue. USI resolved this issue (I can confirm this), and by looking at the source code this may indeed be a "tabID = 0" issue:
Flags: needinfo?(aswan)
Priority: -- → P3
Product: Toolkit → WebExtensions

Can confirm this is happening again in Firefox 66.0.2 on Android 9. Specifically with uBlock Origin, in this case, it does not appear to filter on the first tab, and using the element picker fails. Addtional tabs seem to work fine.

Testing in Nightly with both the current (1.18.6) and an older (1.15.18) version of uBO, I'm not seeing anything particularly strange when looking at
Can anybody confirm an add-on that is still affected in a current Nightly?

Not fixed!

uBO 1.18.16 on today's Nightly is still broken.


  • number of blocked elements should be visible in browser menu in the "uBlock Origin" menu item (in brackets).
  • if you tap on uBO menu entry and select "Element Picker" (pipete), uBO popup interface should close and switch to page - does not happen.

Recent uMatrix issue:, number of blocked elements is not visible in matrix.

Ah okay, I see what you mean now. Thanks for the clarification.

Assignee: nobody → jh+bugzilla

It's easier this way than fixing who knows how many Webextension APIs that have
learned from Desktop that there is no tab #0 and that therefore refuse to work
in our first tab.

Just a little additional information.

On same mobile version I mentioned prior, it appears that sometimes uBlock (presumably other addons as well) also does not work in the second tab. Refreshing that tab seems to cause it to work again. In tab 1 it never works.

It seems to happen when opening a link from tab 0 to a new tab.

Attachment #9056354 - Attachment description: Bug 1410749 - Start tab ID numbering from #1. r?geckoview-reviewers → Bug 1410749 - Start tab ID numbering from #1. r?esawin
Pushed by
Start tab ID numbering from #1. r=geckoview-reviewers,esawin

Backed out for Android 4.3 failures on test_ext_tabs_sendMessage.html



failure log:

[task 2019-04-12T23:20:43.384Z] 23:20:43 INFO - 190 INFO TEST-PASS | mobile/android/components/extensions/test/mochitest/test_ext_tabs_sendMessage.html | tabs.sendMessage
[task 2019-04-12T23:20:43.384Z] 23:20:43 INFO - 191 INFO TEST-PASS | mobile/android/components/extensions/test/mochitest/test_ext_tabs_sendMessage.html | test result correct
[task 2019-04-12T23:20:43.384Z] 23:20:43 INFO - Buffered messages logged at 23:16:26
[task 2019-04-12T23:20:43.384Z] 23:20:43 INFO - 192 INFO AddTask.js | Leaving test tabsSendMessageNoExceptionOnNonExistentTab
[task 2019-04-12T23:20:43.385Z] 23:20:43 INFO - 193 INFO AddTask.js | Entering test tabsSendAndReceiveMessageTabId0
[task 2019-04-12T23:20:43.385Z] 23:20:43 INFO - 194 INFO Extension loaded
[task 2019-04-12T23:20:43.385Z] 23:20:43 INFO - Buffered messages finished
[task 2019-04-12T23:20:43.385Z] 23:20:43 INFO - 195 INFO TEST-UNEXPECTED-FAIL | mobile/android/components/extensions/test/mochitest/test_ext_tabs_sendMessage.html | Test timed out.
[task 2019-04-12T23:20:43.385Z] 23:20:43 INFO - SimpleTest.ok@SimpleTest/SimpleTest.js:275:18
[task 2019-04-12T23:20:43.385Z] 23:20:43 INFO - reportError@SimpleTest/TestRunner.js:121:22
[task 2019-04-12T23:20:43.386Z] 23:20:43 INFO - TestRunner._checkForHangs@SimpleTest/TestRunner.js:142:7
[task 2019-04-12T23:20:53.699Z] 23:20:53 INFO - 196 INFO TEST-UNEXPECTED-FAIL | mobile/android/components/extensions/test/mochitest/test_ext_tabs_sendMessage.html | Extension left running at test shutdown
[task 2019-04-12T23:20:53.700Z] 23:20:53 INFO - SimpleTest.ok@SimpleTest/SimpleTest.js:275:18
[task 2019-04-12T23:20:53.700Z] 23:20:53 INFO - ExtensionTestUtils.loadExtension/<@SimpleTest/ExtensionTestUtils.js:109:18
[task 2019-04-12T23:20:53.700Z] 23:20:53 INFO - executeCleanupFunction@SimpleTest/SimpleTest.js:1236:19
[task 2019-04-12T23:20:53.701Z] 23:20:53 INFO - SimpleTest.finish@SimpleTest/SimpleTest.js:1249:5
[task 2019-04-12T23:20:53.701Z] 23:20:53 INFO - killTest@SimpleTest/TestRunner.js:130:22
[task 2019-04-12T23:20:53.701Z] 23:20:53 INFO - delayedKillTest@SimpleTest/TestRunner.js:157:47

Flags: needinfo?(jh+bugzilla)

Ran into the tests for the few APIs that were fixed to work with tab ID 0.

Flags: needinfo?(jh+bugzilla)
Pushed by
Start tab ID numbering from #1. r=geckoview-reviewers,esawin
Closed: 7 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

Removing regressionwindow-wanted keyword because this bug has been resolved.

Removing regressionwindow-wanted keyword because this bug has been resolved.

Removing regressionwindow-wanted keyword because this bug has been resolved.

You need to log in before you can comment on or make changes to this bug.