Able to reproduce this issue on Windows-10 using chrome latest stable M55-55.0.2883.87  by following steps mentioned in the original comment. 

Bisect Information:
=====================
Good build: 53.0.2760.0 
Bad Build : 53.0.2762.0 

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/0475505c4370a6186fd73ffc9c8ae07af55bf0ae..f01caa59865aec4c79d128e14f4d9fc605e02916

From the above change log suspecting below change
Review URL: https://codereview.chromium.org/1959183002

paulmeyer @ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

Found something weird that might be related to this. 

1. Open a new tab.
2. Open the FindInPage pop-up.
3. Trigger the beep sound by entering backspace after typing something like 'dddddddddddddddddddddddd'.
4. With the FindInPage pop-up still open, click on one of the featured websites shown as squares below the textbox.
5. After navigating to the website, you should hear the beep sound again.

This probably happens because it gets notified about every removed frame and finds the next (or nearest) match (essentially, a "Find next" operation). Since all of the frames are gone, the match count is zero and just like when you press Enter on a query that does not yield any result, it beeps.
https://chromium.googlesource.com/chromium/src/+/c8cb7cbda8636fe756c84b05be2afa70cd9cd3f5/content/browser/find_request_manager.cc#205

Note likely-related  bug 663068 .

Please take this regression seriously; it's minor but extremely annoying and has been occurring for months.

#5 - you mean,  issue 663038 . :)

 Issue 663038  has been merged into this issue.

This was fixed by lazyboy (thanks!) in https://storage.googleapis.com/chromium-find-releases-static/6cc.html#6cce238ff09415dfdb4f6786cfa314a48ae6e8ce

The fix will be in 57 when it ships.

That commit doesn't seem to have anything to do with this bug.

(And indeed, I still get errant dings when searching for text that does not exist and then closing the tab)

Here's a repro case that worked for me on M58 today:

* Open http://google.github.io/styleguide/cppguide.html
* Search for "comment"
* Middle click tab to close it

The CL in #c9 did indeed fix the repro steps in https://bugs.chromium.org/p/chromium/issues/detail?id=663038#c7 but I can repro with #c12 at head. I looked into it briefly, and it seems to be because removing a frame tells the FindRequestManager to update its search results, and there's no distinction between, say, and iframe disappearing and the whole tab closing.

I don't personally think it makes sense for it to beep when an iframe disappears dynamically and that causes the number of find results decreases to zero either.

With that in mind, I posted a not-too-pretty CL here https://codereview.chromium.org/2723253002 that fixes this. Maybe someone else has a better idea that would let the FindRequestManager and FindBarController detect this case though.

Yikes, I'm not sure if plumbing that type of info through is the right thing to do.

I'm pretty swamped right now and will be away next week, but when I get back, I will look into this. I agree that there should be no beep when closing a tab, though I think the beep is probably fine if a frame is removed that had the last of the results. Maybe others have different opinions on this. I could possibly just suppress the re-search if the tab is closing, since the search is meaningless in that case.

I thought the tab closure would be a reasonable signal too, but the frame's removed before the WebContents or the process starts getting nuked, so I'm not sure if that information is available at the right time. (It also needs to handle the navigation case, where the tab isn't going away.)

Anyhow, I'm not attached to that CL, but it's there if we don't come up with something better soon.

From a UX perspective, I'd say we should never cause an audible beep that's not in response to an explicit user action.

The only reason we ding on "no results" to begin with is to alert people who may be heads-down typing that they probably typo'd, so they don't keep typing twenty characters more before they notice.  In that sense, a beep when the final frame that held results is removed is not helping address the reason we added the beep to begin with.

So I would suggest seeking a solution that prevents a "ding" when a drop to zero results is due to a page change and not due to a change in the input text.

With respect to what pkasting was saying about when to audible beep, at least OSX is a platform where there is no beep when a typed match fails to find anything in all the system programs I tried. It is jarring to break this convention.

If what you're saying is that Chrome beeps today in that circumstance but shouldn't, that's valid feedback, but out of scope for this bug.

This bug is about a behavior change where, before Chrome was capable of async find updates, it could not beep in this scenario, and now it can but shouldn't.

@pkasting ah OK. I arrived here via  issue 674109  so I guess when I eventually get a newer Chrome I can check its behaviour and file a new bug as appropriate.

pkasting:

> From a UX perspective, I'd say we should never cause an audible beep that's not in response to an explicit user action.

That matches what I was thinking too. Maybe in https://codereview.chromium.org/2723253002 if I framed that bool in terms of "user action" rather than whether it was in response to a frame removal it'd feel better?

I'm gonna stay out of the technical discussion on how to implement this one because I don't know the code well, unless the relevant OWNERs ask me to weigh in.

Hi, any further thoughts on this? Having left system sounds enabled since looking into it, it's pretty cruddy to have it ding now and then.

It seems like this is still a problem? I can repro a variant of the steps in c#12 with 59.0.3063.0 (M):

* Open http://google.github.io/styleguide/cppguide.html
* Search for "asda" (basically type gibberish until you get a beep)
* Cmd-W to close the tab

It's probably something like the search string gets searched for one last time as you close the window?

#24 - it is not marked as fixed, so, yes, this is definitely still an annoying problem.

I can clean my CL up (#c21) and get it ready to land if we don't have any better ideas.

It seems like we know what we want (don't ding when not in response to an explicit user action) and if there's any remaining question it's only about how to implement it.

I don't see your patch as implementing that.

Beyond the case of frame removal, we also have the case of frame addition: if you perform a failed search on https://whytls.com/test/frames.htm, it dings. Then, when you push the button to add a new frame (that also doesn't contain the search text), Chrome dings again. That seems wrong, and I don't think the CL in #c21 would fix that.

Perhaps the crux of the problem here is that find_result().final_update() is a bit of a lie, because we don't know whether a frame addition or removal will result in "extra" notification with final_update() set in the future. 

Maybe we could most easily fix this by having FindBarController::Observe (and the Mac equivalent) keep track of (on a per-query-string basis) whether it's previously received a final_update() for a given query. If it has, then the call to AudibleAlert() should be skipped. 
 

Beyond #28, it seems like there's possibly a performance optimization to be made  in the event that the entire tab is being blown away-- there's shouldn't be any need to recompute the find results?

I played around with the approach in #28 here: https://codereview.chromium.org/2800163002 and it seems to work for the testcases I tried.

Re #29: It looks like there's an *attempt* not to surface the notification (WebContentsImpl::NotifyFindReply checks is_being_destroyed_ and skips calling the delegate if so) but this doesn't seem to be effective.

I also noticed that this problem occurs on Android, which doesn't beep but does trigger vibration on a failed search (Perform a failed search on https://whytls.com/test/frames.htm and tick the "Random cycle" checkbox to watch your phone dance).

Gah, this has been driving me insane.  It's definitely a regression, and I think it's been happening for at least 6 months or so, so I hope that helps track it down in some way.

I wish I would have reported it earlier.  But it was hard to pinpoint.

RE #32: The regressing change list was identified in Comment #1; this bug was introduced as a side-effect of a change made in Chrome 53.

K, here's a repro on Version 57.0.2987.133 (64-bit).
In https://inbox.google.com, do a find in page for text that doesn't exist, like e.g. "supercalifragilistic".
Get a single beep when find runs out of steam.
Now open/close a chat popup, and notice that every single time you open or close a chat popup, you get a MessageBeep.

Right, that's basically what comment 28 reports, and it sounds offhand like the fix suggested there might be a reasonable one.

Hmm, don't know this code at all, but what I see is that when a new popup opens, RenderFrameImpl::SendFindReply sends a new reply to the browser. When the popup closes, there's no FindReply issued from the renderer. Looking at the browser side now.

Re #36: The CL in #13 shows the code that handles notifications upon frame removal. The CL in #30 shows how you might change the browser side to keep track of "completed" searches to prevent dinging again.

Yeah, looks like a pure browser-side state management gaffe. Here are the two call stacks ending in an infernal <sysbeep> on popup open and close.

# Call Site
00 USER32!MessageBeep
01 chrome_7ffb262d0000!FindBarController::Observe
02 chrome_7ffb262d0000!content::NotificationServiceImpl::Notify
03 chrome_7ffb262d0000!FindTabHelper::HandleFindReply
04 chrome_7ffb262d0000!Browser::FindReply
05 chrome_7ffb262d0000!content::WebContentsImpl::NotifyFindReply
06 chrome_7ffb262d0000!content::FindRequestManager::NotifyFindReply
07 chrome_7ffb262d0000!content::FindRequestManager::FinalUpdateReceived
08 chrome_7ffb262d0000!content::FindRequestManager::OnFindReply
09 chrome_7ffb262d0000!content::WebContentsImpl::OnFindReply
0a chrome_7ffb262d0000!IPC::DispatchToMethodImpl
0b chrome_7ffb262d0000!IPC::DispatchToMethod
0c chrome_7ffb262d0000!IPC::MessageT<FrameHostMsg_Find_Reply_Meta,std::tuple<int,int,gfx::Rect,int,bool>,void>::Dispatch<content::WebContentsImpl,content::WebContentsImpl,content::RenderFrameHostImpl,void (__cdecl content::WebContentsImpl::*)(content::RenderFrameHostImpl * __ptr64,int,int,gfx::Rect const & __ptr64,int,bool) __ptr64>
0d chrome_7ffb262d0000!content::WebContentsImpl::OnMessageReceived
0e chrome_7ffb262d0000!content::RenderFrameHostImpl::OnMessageReceived
0f chrome_7ffb262d0000!content::RenderProcessHostImpl::OnMessageReceived
 # Call Site
00 USER32!MessageBeep
01 chrome_7ffb262d0000!FindBarController::Observe
02 chrome_7ffb262d0000!content::NotificationServiceImpl::Notify
03 chrome_7ffb262d0000!FindTabHelper::HandleFindReply
04 chrome_7ffb262d0000!Browser::FindReply
05 chrome_7ffb262d0000!content::WebContentsImpl::NotifyFindReply
06 chrome_7ffb262d0000!content::FindRequestManager::NotifyFindReply
07 chrome_7ffb262d0000!content::FindRequestManager::RemoveFrame
08 chrome_7ffb262d0000!content::WebContentsImpl::OnFrameRemoved
09 chrome_7ffb262d0000!base::internal::RunMixin<base::Callback<void __cdecl(content::RenderFrameHost *),1,1> >::Run
0a chrome_7ffb262d0000!content::FrameTree::FrameRemoved
0b chrome_7ffb262d0000!content::FrameTreeNode::~FrameTreeNode
0c chrome_7ffb262d0000!content::FrameTreeNode::RemoveChild
0d chrome_7ffb262d0000!content::FrameTree::RemoveFrame
0e chrome_7ffb262d0000!content::RenderFrameHostImpl::OnDetach
0f chrome_7ffb262d0000!base::DispatchToMethodImpl

I'd say https://codereview.chromium.org/2384483004 is the culprit here, as these annoying dings are happening on frame adds/removes. I'll see whether I can figure a quick'n'easy way to elide the dings.

Here's a crazy thought. The beeps currently already only play on two platforms, so would anyone object to them just being removed (i.e. no more beeps on any platforms)?

That's not to say that this can't be corrected to just work the way it did before again, but I believe there are actually a lot of users that are annoyed by the intentional beeps just as much, and nobody has ever requested them to be added on other platforms.

Re #40: I think this is a broader decision that would require approval from the UI reviewers. I suspect some users like the beeps and some do not. 

I should also point out that, as noted in Comment #31, this issue causes unnecessary vibration on Android.

Yeah, let's say that removing beeps entirely is out of scope for this bug.

(And something I'd object to anyway.)

CL here: https://codereview.chromium.org/2839713002/

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

commit 59192dd2dd5d23372ca3ace498327f1c690e61ac
Author: siggi <siggi@chromium.org>
Date: Wed Apr 26 19:41:45 2017

Fix extraneous beeps on empty page search.

As of https://crrev.com/3ac612d592cd42355a432c8d307051d299d79768 a
find-in-page can issue multiple "final updates" if the document changes.
Each time a final update with zero results occurs, there is an audbible
notification which is a nuisance beyond the first one. Particularly
bothersome is that most or all pages cause a ding as you close them if
they have an active find in page with zero results.

BUG=682299

Review-Url: https://codereview.chromium.org/2839713002
Cr-Commit-Position: refs/heads/master@{#467417}

[modify] https://crrev.com/59192dd2dd5d23372ca3ace498327f1c690e61ac/chrome/browser/ui/find_bar/find_bar_controller.cc
[modify] https://crrev.com/59192dd2dd5d23372ca3ace498327f1c690e61ac/chrome/browser/ui/find_bar/find_bar_controller.h

This is a great improvement, but I can still hear extraneous "Dings" in Windows.

Repro:
1. Open https://whytls.com/test/frames.htm
2. Type "Domain" (no quotes) in the Search box
3. Observe: Dings a few times, including at the end of typing
4. Click "Random cycle"

Observe: Frames add/remove; no dings are heard.

5. Switch to a different tab.
6. Type a different search string that fails. Hear a ding.
7. Switch back to the frames.htm tab

Observe: Ding
Expect: No ding

@elawrence: I can repro your case. However, I feel the current behavior is good enough, and I don't have time to work on this any further. Would you like to take ownership of the bug now?

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

commit ea0b89eaf580c7edfae3f61f137dde6c9312bee1
Author: siggi <siggi@chromium.org>
Date: Thu May 04 15:33:37 2017

Test FindBar audible alerts.

BUG=682299

Review-Url: https://codereview.chromium.org/2848883005
Cr-Commit-Position: refs/heads/master@{#469344}

[modify] https://crrev.com/ea0b89eaf580c7edfae3f61f137dde6c9312bee1/chrome/browser/ui/cocoa/find_bar/find_bar_bridge.h
[modify] https://crrev.com/ea0b89eaf580c7edfae3f61f137dde6c9312bee1/chrome/browser/ui/cocoa/find_bar/find_bar_bridge.mm
[modify] https://crrev.com/ea0b89eaf580c7edfae3f61f137dde6c9312bee1/chrome/browser/ui/find_bar/find_bar.h
[modify] https://crrev.com/ea0b89eaf580c7edfae3f61f137dde6c9312bee1/chrome/browser/ui/find_bar/find_bar_host_browsertest.cc
[modify] https://crrev.com/ea0b89eaf580c7edfae3f61f137dde6c9312bee1/chrome/browser/ui/views/find_bar_host.cc
[modify] https://crrev.com/ea0b89eaf580c7edfae3f61f137dde6c9312bee1/chrome/browser/ui/views/find_bar_host.h

I think this warrants a merge to 59, it's such a royal nuisance.

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

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

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

commit b5cf4cfcefca6ace80f3b64dae5186f86092d54c
Author: Sigurdur Asgeirsson <siggi@chromium.org>
Date: Fri May 05 17:20:15 2017

Fix extraneous beeps on empty page search.

As of https://crrev.com/3ac612d592cd42355a432c8d307051d299d79768 a
find-in-page can issue multiple "final updates" if the document changes.
Each time a final update with zero results occurs, there is an audbible
notification which is a nuisance beyond the first one. Particularly
bothersome is that most or all pages cause a ding as you close them if
they have an active find in page with zero results.

BUG=682299

Review-Url: https://codereview.chromium.org/2839713002
Cr-Commit-Position: refs/heads/master@{#467417}
(cherry picked from commit 59192dd2dd5d23372ca3ace498327f1c690e61ac)

Review-Url: https://codereview.chromium.org/2858153005 .
Cr-Commit-Position: refs/branch-heads/3071@{#419}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/b5cf4cfcefca6ace80f3b64dae5186f86092d54c/chrome/browser/ui/find_bar/find_bar_controller.cc
[modify] https://crrev.com/b5cf4cfcefca6ace80f3b64dae5186f86092d54c/chrome/browser/ui/find_bar/find_bar_controller.h

Given comment 46, it seems like either this should be reopened (as available) to cover that, or a new bug should be filed for that.

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

commit ce0335b002d09ff87b4a7eace6f9713ef421b854
Author: Sigurdur Asgeirsson <siggi@chromium.org>
Date: Fri May 05 19:52:51 2017

Fix build break due to missing include.

BUG=718975,682299

TBR=pkasting@chromium.org

Review-Url: https://codereview.chromium.org/2864463005 .
Cr-Commit-Position: refs/branch-heads/3071@{#424}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/ce0335b002d09ff87b4a7eace6f9713ef421b854/chrome/browser/ui/find_bar/find_bar_controller.h

Re-opening as my fix doesn't entirely fix the dings, see comment #46.

There's a 100% repro for me on 60.0.3088.3 (Official Build) dev (64-bit) (cohort: Dev):

1. Navigate to https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/FrameView.cpp?q=FrameView.cpp&dr&l=4931
2. Press Ctrl^F
3. Type To2. This will probably ding (though slightly delayed, as the renderer needs to notify the browser there are no matches).
4. Press backspace to delete one character.
5. Type RemoteFrame.

The final string in the search box should be ToRemoteFrame.

6. Press ^W
7. DING!

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

commit 8e81b8169945aadb5b2ce55577d1979ce37a4add
Author: siggi <siggi@chromium.org>
Date: Tue May 09 18:09:16 2017

Add a missing include that broke the M59 beta build.

BUG=718975,682299

Review-Url: https://codereview.chromium.org/2864463005 .
Cr-Original-Commit-Position: refs/branch-heads/3071@{#424}
Cr-Original-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}
Review-Url: https://codereview.chromium.org/2867773002
Cr-Commit-Position: refs/heads/master@{#470383}

[modify] https://crrev.com/8e81b8169945aadb5b2ce55577d1979ce37a4add/chrome/browser/ui/find_bar/find_bar_controller.h

Verified this issue on Windows-10 and Mac OS 10.12.4 using chrome latest beta M59-59.0.3071.47 by following steps mentioned in the original comment, Observed no ding sound is heard while navigating back to the pages. Hence adding TE-Verified label.

Not Verified -- the bug is not completely fixed (comments 46, 55, 56).

Interesting repro in comment 56 - works for me too.

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

commit cf97ed5bc86f3ec5ede7392671b7cc2e6d9a85dd
Author: Sebastien Marchand <sebmarchand@chromium.org>
Date: Mon Jul 24 23:50:34 2017

Disable the FindReply beeps during a tab's shutdown.

Fix the system beep that happen when closing a tab in some situations 
(see this repro: https://bugs.chromium.org/p/chromium/issues/detail?id=682299#c56)

This is probably not the best way to fix this bug but it's probably a
sufficient workaround until we find a better fix.

Bug: 682299
Change-Id: I3a6c08cb01d3c2f6de1a8a2fee53a43eefde1e4d
Reviewed-on: https://chromium-review.googlesource.com/581571
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Paul Meyer <paulmeyer@chromium.org>
Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org>
Cr-Commit-Position: refs/heads/master@{#489146}
[modify] https://crrev.com/cf97ed5bc86f3ec5ede7392671b7cc2e6d9a85dd/content/browser/web_contents/web_contents_impl.cc

My fix seem to address all the remaining issues, I can't repro this anymore.

Should it be merged to M61? Theses beeps are really annoying

The fix seems simple (thanks!), but given that this was broken from M53-M61, it may be hard to argue that it's critical to merge this. Maybe set the flags and let the M61 release owner decide?

Incidentally, the repro steps in #46 still exhibit the problem, as they don't involve a tab shutdown. In practice, however, I'd expect tab shutdown represents most of the user-encountered repros.

Ha, I'll see what I can do about the repro in #46. I'll set the flag and I'll let the M61 release owner decide.

Release owner: Merge request is for https://chromium.googlesource.com/chromium/src.git/+/cf97ed5bc86f3ec5ede7392671b7cc2e6d9a85dd

Seb, assigning to you, since you're looking at this anyways. I think to close the #46 case, you'll have to relocate the alerted_search string to the FindTabHelper instance, as that has tab affinity, rather than window affinity. 

Your change meets the bar and is auto-approved for M61. Please go ahead and merge the CL to branch 3163 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid @(ChromeOS), govind@(Desktop)

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

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

commit 8918bdf1457724bf7286bdb77c2785efbb446e45
Author: Sebastien Marchand <sebmarchand@chromium.org>
Date: Wed Jul 26 15:20:45 2017

Disable the FindReply beeps during a tab's shutdown.

Fix the system beep that happen when closing a tab in some situations
(see this repro: https://bugs.chromium.org/p/chromium/issues/detail?id=682299#c56)

This is probably not the best way to fix this bug but it's probably a
sufficient workaround until we find a better fix.

TBR=sebmarchand@chromium.org

(cherry picked from commit cf97ed5bc86f3ec5ede7392671b7cc2e6d9a85dd)

Bug: 682299
Change-Id: I3a6c08cb01d3c2f6de1a8a2fee53a43eefde1e4d
Reviewed-on: https://chromium-review.googlesource.com/581571
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Paul Meyer <paulmeyer@chromium.org>
Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#489146}
Reviewed-on: https://chromium-review.googlesource.com/586918
Reviewed-by: Sébastien Marchand <sebmarchand@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#56}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/8918bdf1457724bf7286bdb77c2785efbb446e45/content/browser/web_contents/web_contents_impl.cc

I'll take care of the remaining issue (from repro in c #46) later.

Verified this issue on Windows-7 and Mac OS 10.12.6 using chrome latest Dev # 61.0.3163.25 by following steps mentioned in the comment #56. After pressing Ctrl+W the window got closed and no ding sound has observed. 

This bug seems to be back again.

Windows 10
67.0.3396.87

*** UI Mass Triage ***

We were unable to reproduce this bug. If this bug still reproduces for you, 
please reopen or file a new issue. 
Thanks!

Still repros