Opened on 03/16/2018 at 03:01:04 PM

Closed on 11/08/2018 at 09:00:11 PM

Last modified on 02/18/2019 at 11:48:13 AM

#6490 closed defect (fixed)

"browserAction.setIcon: No tab with id" error after using block element in Chrome

Reported by: Ross Assignee: jsonesen
Priority: P2 Milestone: Adblock-Plus-3.5-for-Chrome-Opera-Firefox
Module: Platform Keywords:
Cc: kzar, sebastian Blocked By:
Blocking: Platform: Chrome
Ready: yes Confidential: no
Tester: Ross Verified working: yes
Review URL(s):

Description (last modified by kzar)


Chrome 49 / 62 / Windows 7

Could not reproduce in Firefox or Opera.

How to reproduce

  1. Navigate to a website (any).
  2. Select [ABP Icon] > [Block element].
  3. Select an element (any) and OK the dialog.

Observed behaviour

The element is hidden as expected however the following error appears in the console (tab id varies):

    extensions::lastError:133 Unchecked runtime.lastError while running browserAction.setIcon: No tab with id: 34.
    reportIfUnchecked @ extensions::lastError:133
    handleResponse @ extensions::sendRequest:78

Expected behaviour

Error to not occur/be handled.

Attachments (0)

Change History (14)

comment:1 Changed on 03/19/2018 at 03:31:46 PM by kzar

  • Description modified (diff)
  • Priority changed from Unknown to P3
  • Ready set

I can reproduce this, seems it's only when the filter generated is a request blocking rather than element hiding one.

comment:2 Changed on 03/19/2018 at 10:55:26 PM by sebastian

  • Priority changed from P3 to P2

Reproduced, here, as well. This seems to be a regression since the last release for Chrome (1.13.5). However, if this is the only known regression, and since it doesn't seem to have any visible effects to the user, it seems ok if we fix this with Adblock Plus 3.0.4, rather than blocking the 3.0.3 release.

comment:3 Changed on 05/22/2018 at 06:53:37 PM by jsonesen

  • Owner set to jsonesen

comment:4 follow-up: Changed on 05/23/2018 at 11:59:21 AM by sebastian

It appears to be a race condition: When any filter is added (or removed) we update the icon for each tab and window (including the "Block element" dialog). By the time borwser.tabs.query({}) is called the "Block element" dialog still exists, but by the time we update the icon (a couple milliseconds later) it has been removed causing this error.

comment:5 in reply to: ↑ 4 Changed on 05/24/2018 at 12:05:11 AM by jsonesen

Replying to sebastian:

By the time borwser.tabs.query({}) is called the "Block element" dialog still exists, but by the time we update the icon (a couple milliseconds later) it has been removed causing this error.

In this case should we first check the dialogue exists? or do you think it is better to catch the error and continue?

comment:6 Changed on 05/24/2018 at 02:57:55 PM by sebastian

Though less likely, there can be other windows/tabs (besides the "Block element" dialog) getting removed in between detecting filter changes and updating the icon. So I don't think that simply ignoring the "Block element" dialog would be an appropriate solution.

I wonder if we can mitigate the race condition if call browser.borwserAction.set*() imediatelly rather than first checking if the tab exists first.

Otherwise, (while not great) silencing the error seems to be the best option left.

comment:7 Changed on 05/26/2018 at 02:29:46 AM by jsonesen

It looks like commenting out the tab.get block stops the error.

comment:8 Changed on 05/27/2018 at 02:14:57 PM by sebastian

We still need to handle the scenario of pre-rendered tabs, but perhaps we can just handle browserAction.set*() failing first to not defer the action unnecessarily in the common case.

comment:9 Changed on 05/29/2018 at 09:11:37 PM by jsonesen

It seems we already catch errors in setIcon() for Edge here perhaps I can check the error message at the start of the catch and silence the error? Should avoid common case handling too.

That's exception handling whoops, but adding a callback to the setIcon call which reads browser.runtime.lastError works and avoids running the check on all set* but doesn't avoid it for common setIcon case.

Last edited on 05/29/2018 at 11:03:57 PM by jsonesen

comment:10 Changed on 05/29/2018 at 11:07:39 PM by jsonesen

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

comment:11 Changed on 11/08/2018 at 08:59:38 PM by jsonesen

A commit referencing this issue has landed:
Issue 6940 - Wrap browser.browserAction.set* with promise

comment:12 Changed on 11/08/2018 at 09:00:11 PM by jsonesen

  • Milestone set to Adblock-Plus-for-Chrome-Opera-Firefox-next
  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:13 Changed on 11/08/2018 at 09:01:58 PM by jsonesen

  • Review URL(s) modified (diff)

comment:14 Changed on 02/18/2019 at 11:48:13 AM by Ross

  • Verified working set

Fixed. Error no longer occurs when using Block element.

Firefox 65.0.1 / 51 / Windows 10
Firefox Mobile 65.0.1 / Android 7.1.1
Chrome 72.0.3626.109 / 49.0.2623.75 / Windows 10
Opera 58.0.3135.65 / 36.0.2130.80 / Windows 10
Edge 44.17763.1.0 / Windows 10

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from jsonesen.
Note: See TracTickets for help on using tickets.