Tested this issue on Ubuntu 14.04 using chrome stable M55-55.0.2883.87 by following steps mentioned below.

1. Installed chrome extension https://chrome.google.com/webstore/detail/yathit-sugarcrm-for-gmail/iccdnijlhdogaccaiafdpjmbakdcdakk
2. Clicked on the extension icon and navigated to options
3. Clicked on Login and selected gmail account
4. Observed no behavior after selecting the gmail account.

kyawtun@ As you mentioned in the original comment, Could you please provide a minimal test case of this issue for further triaging.

Thanks!

Here is solid proof of recent bug. Screenshoot http://g.recordit.co/HasKzDtlFI.gif 

Please install attached extension. 

A Positive and an Test buttons should show on any web page from the content script.

Click 'Positive', it request optional permission.

Click 'Test', it fail to request optional permission saying "This function must be called during a user gesture", even though it is invoked by user gesture. 

This is working before around Chrome 53. 

Deleted: permission-req-bug.zip 11.7 KB

permission-req-bug.zip 11.7 KB Download

Tinkering workaround with window.confirm https://github.com/yathit/permission-req-bug

Clearly it is user gesture, but working :-(

I should go with <all_urls> permission. Sweet!!!

Bisect using the extension from #2:
420838 (good) - 420839 (bad), 55.0.2872.0
https://chromium.googlesource.com/chromium/src/+log/2e70970b..9027b8ba?pretty=fuller
The only change in the range is r420839 "Queue a close event for dialog.close" -  issue 380087 .

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Cleaning up "Needs-Review" label as we are not using this label for triage. Ref  bug 684919 

Could someone take a look?

As per bisect information provided in comment #4 adding @xing.xu for more updates on this issue.

Thanks!

Thanks for the bisect, woxxom@!  That definitely sounds like the culprit.

By asynchronously closing the dialog, I'm suspecting we lose track of the fact that there was a user gesture being processed, which is what we use to determine if an extension function is called with a user gesture.  We need to curry that information through to the dialog close (e.g. with user gesture tokens).

Assigning to skobes@, who reviewed r420839, and updating the summary.

Hi, I tried to revert this patch locally on Ubuntu as follows, "This function must be called during a user gesture" will gone:
--- a/third_party/WebKit/Source/core/html/HTMLDialogElement.cpp
+++ b/third_party/WebKit/Source/core/html/HTMLDialogElement.cpp
@@ -125,7 +125,7 @@ void HTMLDialogElement::CloseDialog(const String& return_value) {
   if (!return_value.IsNull())
     return_value_ = return_value;
 
-  ScheduleCloseEvent();
+  DispatchScopedEvent(Event::Create(EventTypeNames::close));
 }

Issue analyze:
PermissionsRequestFunction::RunAsync(chrome\browser\extensions\api\permissions\Permissions_api.cc) will check if current call is inside a user_gesture(). If not, will throw this error.

So If we queue the dialog.close as https://html.spec.whatwg.org/multipage/forms.html#close-the-dialog does, this dialog.close will be outside of a user_gesture(). That's why error being throw.

I have little about the extension permission, any other idea about this?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

This still needs to be fixed. Marking available.