search

arikw / chrome-extensions-reloader

A chrome extension for reloading unpacked extensions
https://chrome.google.com/webstore/detail/extensions-reloader/fimgfedafeadlieiabdeeaodndnlbhid
Apache License 2.0
276 stars 38 forks source link

Recent updates result in "reload.extensions is blocked" #20

Closed russelldavis closed 2 years ago

russelldavis commented 3 years ago

50% of the time when I use this extension (navigating to http://reload.extensions), it results in an error page saying "reload.extensions is blocked".

I downloaded the extension and confirmed that the bug does not happen at https://github.com/arikw/chrome-extensions-reloader/commit/bc2c308be360adc1f00e2cbbbd81f3e08466c237, but it does start happening at https://github.com/arikw/chrome-extensions-reloader/commit/8d206275a719c6bce1a4d133d88d1be35290c6f1.

I suspect the problem is the line that returns { cancel: true } from the onBeforeRequest listener.

Screenshot

Screen Shot 2021-09-01 at 9 27 12 AM
russelldavis commented 3 years ago

I've reproduced this in Chrome 92 and 93.

user8446 commented 3 years ago

Reproduced in Chrome beta 94 but the toolbar button works as expected

arikw commented 2 years ago

@russelldavis Thank you. The { cancel: true } was introduced in this PR to fix the reload loop bug. Does an extension reload occur when you browse to http://reload.extensions and see the error page?

user8446 commented 2 years ago

On my machine (currently Chrome 95 beta) even though the block page appears the toolbar button displays "ok" so it's still receiving the request

arikw commented 2 years ago

So the underlying problem is that the newly created tab with http://reload.extensions not being automatically closed

russelldavis commented 2 years ago

This happens even when there's no newly created tab (if you navigate to http://reload.extensions in an existing tab). The problem is returning { cancel: true } in onBeforeRequest. #21 fixes it.

russelldavis commented 2 years ago

Regarding https://github.com/arikw/chrome-extensions-reloader/issues/20#issuecomment-933407100 (sorry, I missed that comment earlier), I'm pretty sure { cancel: true } is not necessary to fix that bug. I've been using the extension with my change in #21, and I can't reproduce the reload loop.

arikw commented 2 years ago

This is the desired logic:

Scenario A: "Reload current tab after extensions have been reloaded" option turned-off

1) If a new tab is created, it should be closed 2) If an existing tab is about to navigate to the "reload url", it should not navigate to that url and leave the existing page in the tab as-is

Scenario B: "Reload current tab after extensions have been reloaded" option turned-on

1) If a new tab is created, it should be closed and the last used tab should be refreshed 2) If an existing tab is about to navigate to the "reload url", it should not navigate, leave the existing page in the tab as-is and reload that tab

There're 3 technical methods to invoke the reload X) Pressing the toolbar button (same as keyboard shortcut) Y) Navigating to http://reload.extensions/ via the address bar Z) Using an external tool (e.g. start http://reload.extensions/ on windows cli)

Currently, I see 2 problems:

  1. Scenario A>2 using method Y causes a "blocked page" error to be shown (the problem you've reported about) instead of leaving the page as-is
  2. Scenario B>2 using method Y causes a the last tab in the window to be refreshed, instead of the last viewed one. Not sure why it stopped working.

Do you see the blocked page" error occurring using a method other than methodY`?

Regarding PR #21 : it might fix probelm 1 but all other scenarios invoked with all reload invocation methods should be tested and a regression bug should be ruled out