This may also be affecting win 7, but not confirmed yet. Expected behavior can be seen on Win 10 and Linux

Able to reproduce the issue on Mac 10.13.6 using chrome reported version #72.0.3611.0 and latest stable #70.0.3538.102. Issue is specific to OS-mac.
This is a non-regression issue as it is observed from M60 old builds. 
Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

removing block on M72 launch as Mac launch is planned for M73

I tried to run a bisect on this issue, but it's reproducible as far back as M65. I couldn't get the revision for M64 to go back further back.

Are you using the automatic bisect-builds.py tool? It should be able to go way back (I've gone all the way to M59 in the past).

Omaha isn't giving me revision number for older builds, the command I'm running needs both good and bad revisions to bisect.

command I'm running:

python tools/bisect-builds.py --use-local-cache --verify-range -a $platform -g $goodRevision -b $badRevision

Is there a different way that I should use it? I can also try an arbitrary smaller revision but it won't be tied to a specific release.

w/ arbitrary smaller revision number this does NOT work in 53.0.2769.0, so this may have been broken a very very long time or is specific to the mac version on my computer (Mac OS High Sierra 10.13.6)

This is currently our only blocker for launching project Navi (new onboarding) on Mac. Help from someone more familiar with Mac would be very helpful

@ellyjones: Is there anyone on the Mac team that could help with this one?

Hm - I'm not positive that there is such a notification from the system on Mac. I'll consult with some experts and get back to you.

Hi, I'm following up on #17 to see if there's a notification from the system.

We would need this for a new user experience on-boarding launch in M73. We've created a possible workaround here https://crrev.com/c/1408028 in case the system can't provide a notification. Polling is not as clean, but it would unblock us for M73.

I have investigated this - here's what I have tried:

1) Registering for all notifications in [NSNotificationCenter defaultCenter]
2) Registering for all notifications in [[NSWorkspace sharedWorkspace] notificationCenter]
3) Registering for the "com.apple.system.logger.message" notification in CFNotificationCenterGetDarwinNotifyCenter() (I thought there might be an ASL message when the default browser changes). You can't register for all notifications in this center, but I found a list here: <https://www.midnightbsd.org/pipermail/midnightbsd-cvs/Week-of-Mon-20160808/039990.html>. None of the other ones seem likely to be useful.
4) Registering for all notifications in CFNotificationCenterGet{Distributed,Local}Center()

None of these get any notification when the default browser changes. I think you're going to need to either:

a) Fire off the change request and assume that it worked, or
b) Poll for a short time (maybe a couple tens of seconds?) after sending the request to check whether it completed

Either way, I wouldn't poll any faster than probably 10Hz.

So, short version: this bug is WontFix / infeasible :(

Thanks for the investigation, Elly! We'll move forward w/ recommendation B and poll for a short time.

Ah, sdy@ pointed me at an undocumented notification: you can maybe listen for user.uid.$UID.com.apple.LaunchServices.database on CFNotificationCenterGetDarwinNotifyCenter(). That seems to be delivered 5-6 times when the default browser changes. Unfortunately it has no userInfo, so there's no way to tell what the notification is actually *for*, but listening for this and then checking whether the default browser has changed might be better than polling. I'm unsure, so feel free to go with whatever design works best for you.

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

commit b32baff095a0665fd13de761e0089da20793e768
Author: Hector Carmona <hcarmona@chromium.org>
Date: Fri Jan 18 02:14:12 2019

Navi: Poll for default browser change while onboarding.

This is necessary because on Mac OS we cannot get a system notification
when the default browser is changed. We need to poll until it has
changed so that we can progress through the flow.

Bug:  905895 
Change-Id: I636b18fdf31d75379378ac4bf33a030e448aa7bd
Reviewed-on: https://chromium-review.googlesource.com/c/1408028
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Hector Carmona <hcarmona@chromium.org>
Cr-Commit-Position: refs/heads/master@{#623958}
[modify] https://crrev.com/b32baff095a0665fd13de761e0089da20793e768/chrome/browser/resources/welcome/onboarding_welcome/set_as_default/nux_set_as_default.js