Rubenspgcavalcante@,
Thanks for filing the issue.
Could you please provide us the sample extension to triage this issue further.

Hello mukthavaram@, thanks for the response!
Ok, I've added a sample extension that triggers the Fast Reload blocking.
In this sample I've didn't added the websocket mechanism to trigger the reloading, as I do in my plugin, https://github.com/rubenspgcavalcante/webpack-chrome-extension-reloader, just to maintain it simple to reproduce.

Deleted: Fast Reload Sample.zip 934 bytes

Fast Reload Sample.zip 934 bytes Download

Thank you for providing more feedback. Adding requester "jmukthavaram@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested on Chrome Stable #59.0.3071.109 and in the reported version #58.0.3029.110 on Mac 10.12.5 but the issue was not reproducible.
 
Steps followed:
1. Launch Chrome and load unpacked extension.
2. In Chrome Console, call chrome.runtime.reload for 6 times.
3. While screen reloading user is able to disable and enable the extension.
 
@rubenspgcavalcante -- Please find the attached screen-cast for the above steps and let us know if we have missed anything.

Note: Same behavior is noticed on Windows 10 and Ubuntu 14.04
 
Thanks in advance.

Deleted: 733209.mp4 1.6 MB

	733209.mp4 1.6 MB View Download

Hello pnangunoori@, thanks for response!
I think there's a misunderstood. You disabled the plugin before it triggered the "fast reload" block. Please add the plugin and wait a least 10 sec., so it can trigger the block (like in the screenshot attached).
And anyway, I don't want to *manually* reload the extension, that's why I'm asking for a way to disable this "fast reload" block for *unpacked* extensions. Can be in the settings, or even in the manifest.json of the extension itself. This way, hot reloading mechanisms can work properly. :)

Best,

Deleted: Screen Shot 2017-06-23 at 13.48.19.png 141 KB

	Screen Shot 2017-06-23 at 13.48.19.png 141 KB View Download

Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sorry, I think it should change the type of this request from "Bug" to "Feature", as creating a way to disable the block for unpacked features is more an improvement

As per comment #9, MArking this as feature request and untraiging , to get this addressed by respective team.

Thanks!

Please address this issue, it's creating a really bad developer experience by making impossible the autoreloading of the extension when a file changes.

Here is the commit that introduced it: 
https://chromium.googlesource.com/chromium/src/+/e9d7496ee1703754c5d56027aa2758a09c473c0a

Since in the message it says that it's done to prevent the extension from getting "stuck in a loop reloading itself", I think it would be more reasonable to check in intervals lower than a second, instead of ten seconds.

Hope you guys will hear this feedback.

Yeah, I can see how this would be annoying.  The limits are probably unnecessarily strict.  I think we can probably relax these a bit.

catmullings@, this could be a good one for you to take?

Hey. Is it possible to bump this issue up a bit? As a chrome extension developer this breaks my flow on a daily bases. 

Thanks

Will a patch that changes kFastReloadTime from 10000 to 1000 be accepted? This issue is quite annoying when trying to do hot-reloading during extension development.

I was also able to reproduce this today - it's definitely a hurdle for chrome extension development.

From https://github.com/drewio/crx-hotreload/commit/1d8b176c0c399bb884377e7fa01345fd85718d52 it looks like chrome.developerPrivate.reload might not have this limitation:

https://developer.chrome.com/apps/developerPrivate#method-reload

@16 Patches are always welcome!  Unfortunately, I don't think we'd want to unconditionally change the constant to 1000ms, because that's still much more frequent than we'd want for non-development extensions.  Instead, we'd want separate thresholds for unpacked extensions and packed extensions.  That's still very much doable, and if you wanted to take a stab at writing that patch, I'm very happy to review it.

@19: Can you confirm that chrome.developerPrivate.reload doesn't have this limit? If so I don't think we need to mess with chrome.runtime.reload :)

Correct, developerPrivate does not have this limitation.  However, developerPrivate is restricted to whitelisted apps and extensions (designed to only be used by components of Chrome itself).  If it's *really* just for development and you don't mind building a modified version of chromium, it will work, but you won't be able to easily use it on a build of Chrome.

still not fixed? please fix! 

any update on this issue?

I would also love this feature to be implemented. It totally breaks autotests of my extension in puppeteer. 

And it is also very difficult to find this reason of failing tests - I've spent several hours until found it.

Kelvin, could you take a look at this when you have time?

I'm looking for solutions to hot reload extensions as well. Can we expose the chrome.developerPrivate.reload(id) API or something similar that:

1. Does not have the time limit for development extensions.
2. Allows us to reload *any* development extension by ID (instead of chrome.runtime.reload()). 

Kelvin, it sounds like there are a few motivated folks who are keen to help if there's an opportunity. Please let us know!

What I propose is:

1) reduce the fast reload time from 10s to 1s for unpacked extensions
2) increase the fast reload count (number of times an extension can be reloaded faster than the fast reload time before being forcibly disabled) to ~20/30 for unpacked extensions (so if an unpacked extension continually reloads, it can get flagged before it's packed).

^this should make unpacked testing easier while still disabling an extension if it tries to reload too much and potentially cause the browser to deadlock.

I'll also add a note mentioning that extensions should also be tested in their packed form as 

Of course, these numbers can change, please let me know if these values are good or what alternative values should be considered.

Seems reasonable, as a person will not be so quick saving files and triggering the hot-reload in such small time.

Thanks for taking this one :) 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d3b25e1380984b2f1f23d0e8dc1a337743c6caaf

commit d3b25e1380984b2f1f23d0e8dc1a337743c6caaf
Author: Kelvin Jiang <kelvinjiang@chromium.org>
Date: Mon Dec 10 20:40:23 2018

[Extensions] Increase reload leniency for unpacked extensions

Decrease reload interval for unpacked extensions to 1s and increase
reload count to 30 before disabling the extension. This should make it
easier for developers to test their unpacked extensions while still
preventing browser deadlocks from extensions which reload too often.

Bug:  733209 
Change-Id: I75467a4e6910696e4c12f34304222f3d46a4e11f
Reviewed-on: https://chromium-review.googlesource.com/c/1340272
Commit-Queue: Kelvin Jiang <kelvinjiang@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#615236}
[modify] https://crrev.com/d3b25e1380984b2f1f23d0e8dc1a337743c6caaf/chrome/browser/extensions/api/runtime/chrome_runtime_api_delegate.cc
[modify] https://crrev.com/d3b25e1380984b2f1f23d0e8dc1a337743c6caaf/chrome/browser/extensions/api/runtime/chrome_runtime_api_delegate_unittest.cc

Marking as closed for now, will re-open if a similar issue comes up again for anyone.