timloh@ - do you mind having a first look at this? I'll cc myself too to have a look in case you can't.

Are you able to repro in stable or beta? I tried on stable and couldn't repro.

Me too, unable to repro this in stable. 

It doesn't reproduce on stable or beta, I can only reproduce it on Canary. so it looks like a recent regression.

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

 Issue 821661  may be a dupe of this.

I think  issue 816033  was supposed to fix this but may have inadvertently caused a regression.

+cc mkwst, whose team is taking over permissions. I don't think SYD has bandwidth to look into this any more unfortunately, so we may need to pass to you.

+cc estark FYI.

Assigning to guidou since I think there's a good chance this is related to  issue 816033 .

I didn't manage to repro (on Linux) but we should probably check whether accepting the prompt actually grants permission; we've had several bugs like this in the past where usually the prompt ends up being 'dead' and not actually granting/denying permission.

This issue is marked as a release blocker with no OS labels associated. Please add an appropriate OS label.

All release blocking issues should have OS labels associated to it, so that the issue can tracked and promptly verified, once it gets fixed.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

timloh@: Can you reproduce reliably? If so, can you provide some details about your environment?
I have been unable to reproduce on any device or chrome version so far.

timloh@: Ignore #12. I misread your comment as "I did manage to repro".

krajshree@: Since you were able to reproduce  bug 821661 , can you try to reproduce this one?
I have been unable to reproduce it so far on any platform or Chrome version.

Pls apply appropriate OSs label.

This is repro only on Windows or Linux.

chromium.khalil@: Can you provide more details about hardware/OS that you use for reproduction?

I'm able to repro this only on Windows (Virtual-box) on Canary and not on stable or dev.

1. Set up a local webserver to host testcase.html
2. Load 127.0.0.1/testcase.html
3. Click on button and wait for the navigation to google.com
4. Observe the permission request stays open after navigation to google.com

I repro-ed this very easily.

chromium.khalil@: Per #18 it looks like you can also repro on Linux. Any particular configuration details there?

ubuntu 16.04 4Gb RAM (on Virtual-box).

Guidou@, are you able to repro this on Windows?

Hmm... after confirmation, I believe this only affects Windows, I couldn't repro on Linux either (Comment 18 - sorry, my mistake).

Weird, I can repro this with the testcase of  issue 816033  on canary 67.0.3395.0 on Windows. (recently I wasn't able to repro it after fixing  issue 816033  on canary)

Deleted: screen_1.mov 1.2 MB

	screen_1.mov 1.2 MB View Download

Deleted: poc (5).html 314 bytes

poc (5).html 314 bytes View Download

Making this bug available since I cannot reproduce on any platform and cannot act on it.
I will gladly assist anyone who can provide actionable info, such as bisect results or alternative repro steps.

 chromium.khalil@, based on #27, it sounds like you can no longer repro this issue on latest Canary?  Maybe it is fixed by  issue 816033 ?  

 Issue 821661  has been merged into this issue.

I meant I’m still able to repro this issue with using two different PoCs on the latest version of Canary on Windows.

Note: This doesn't repro on Chromium build.

OP -- I tried repro'ing it on 68.0.3397.0 (Canary) on Windows and still can't reproduce it. I'm afraid if we don't have better repro steps, we'll need to mark this as WontFix.

Could you please try it with the latest Canary and report back with a POC that repros reliably?

Tested on 68.0.3399.0 on Windows 7.

1. Set up a local webserver to host testcase.html
2. Load http://127.0.0.1/testcase.html
3. Click on the button 
4. Observe 

Deleted: Recording #3.mp4 370 KB

	Recording #3.mp4 370 KB View Download

Deleted: testcase.html 314 bytes

testcase.html 314 bytes View Download

If you can't repro it again, Could you please add a video of you trying to repro? it may be helpful.

Still can't repro it. I've attached a video capture.

Deleted: crbug.com_822957.webm 4.3 MB

	crbug.com_822957.webm 4.3 MB View Download

We've gone back and forth on this so I'm going to mark it as WontFix for now. Please feel free to re-open if there's another way to repro it more reliably. Thanks.

Hmm... based on comment 37, the problem you have is the permissions are already blocked.

Microphone permission shouldn't be allowed or blocked on the page. as on my devise.

Deleted: Screen Shot 2018-04-21 at 00.09.10.png 113 KB

	Screen Shot 2018-04-21 at 00.09.10.png 113 KB View Download

> problem you have is the permissions are already blocked.

I don't have that permission blocked.

Can you also please explain what part of #c37 indicates that I have it blocked already?

Well, on your video in comment 35, after clicking on the button to repro, the permission request bubble didn't display because was blocked already. 

Deleted: Screen Shot 2018-04-21 at 01.46.17.png 114 KB

	Screen Shot 2018-04-21 at 01.46.17.png 114 KB View Download

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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