Opened 5 years ago

Closed 5 years ago

#1843 closed defect (fixed)

"Block element" dialog keeps showing when extension is disabled/uninstalled/reloaded

Reported by: greiner Assignee: sebastian
Priority: P3 Milestone: Adblock-Plus-1.8.11-for-Chrome-Opera-Safari
Module: Platform Keywords:
Cc: Blocked By:
Blocking: Platform: Unknown
Ready: yes Confidential: no
Tester: Verified working:
Review URL(s):

http://codereview.adblockplus.org/5186743326212096

Description (last modified by sebastian)

Environment

Ubuntu 14.04
Chrome 39

How to reproduce

  1. Go to any webpage (e.g. google.com)
  2. Click on "Block element" in the Adblock Plus icon popup
  3. Select any element on the page (block.html is shown within a frame)
  4. Disable the Adblock Plus extension
  5. Go back to the webpage

Observed behaviour

  • block.html is still shown on the page
  • Neither clicking on "Cancel" nor "Add" closes the dialog

This behavior persists even after the extension was reenabled.

Expected behaviour

All DOM modifications should be undone when the extension is disabled/uninstalled/reloaded.

Change History (7)

comment:1 Changed 5 years ago by sebastian

When the extension is disabled/removed/relaoded, all attempts to message the background page fail. Hence the dialog won't be functional anymore. Technically we could close the dialog without messaging, however the selected elements would still stay highlighted. Since they might be in a different frame, messaging is required here. Also the "Add" button would still not work. So this isn't a solution.

If there is a way to get notified in the content script when the extension is unloaded, we should automatically remove the dialog and undo the highlighting instead. If there isn't such an option, I'd rather in the favor to close this issue as rejected.

comment:2 Changed 5 years ago by sebastian

  • Cc sebastian added

comment:3 Changed 5 years ago by greiner

Unfortunately, there doesn't appear to be an event we could listen to for that purpose. However, there is a relevant Chromium issue and until then we could at least handle the messaging errors appropriately e.g. by overlaying a message for the user with an "OK" button to, upon clicking, undo any DOM modifications.

comment:4 Changed 5 years ago by sebastian

As I said you might still need to communicate between frames to undo all DOM modifications. And waiting for an error (usually triggered by user interaction) isn't as smooth as immediately reverting DOM modifications when the extension is unloaded. This is what the user expects when he disables/uninstalls an extension after all. Also you might not be able to catch those errors, if they occur asynchronously.

However, it might be possible to create a port with chrome.runtime.connect() and listen to it's onDisconnected event. It should be fired in the content script when the background page dies. Then we could implement ext.onExtensionUnloaded using ports under the hood.

Last edited 5 years ago by sebastian (previous) (diff)

comment:5 Changed 5 years ago by sebastian

  • Cc sebastian removed
  • Description modified (diff)
  • Owner set to sebastian
  • Priority changed from Unknown to P3
  • Ready set
  • Summary changed from Cannot close block.html frame if extension got disabled while it was open to "Block element" dialog keeps showing when extension is disabled/uninstalled/reloaded

Awesome, that actually works.

comment:6 Changed 5 years ago by sebastian

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

comment:7 Changed 5 years ago by sebastian

  • Milestone set to Adblock-Plus-for-Chrome-Opera-Safari-next
  • Resolution set to fixed
  • Status changed from reviewing to closed
Note: See TracTickets for help on using tickets.