Affected versions

• 74.0a1 (20200207035551)

Affected platforms

• Windows 10x64
  Steps to reproduce

1. Open Firefox and go to about:preferences#privacy.
2. Observe the “Notifications” section from “Permissions area”

Expected result

• “Pause notifications until Firefox restarts” is presented.

Actual result

• “Pause notifications until Firefox restarts” no longer displayed.

Regression Range

• Last good revision: 25ec03d2ae24ec7e5f50bf959240694dbd4a30ec
• First bad revision: f0955f658b1e02949555c212e0af501abca60ded
• Pushlog:
  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=25ec03d2ae24ec7e5f50bf959240694dbd4a30ec&tochange=f0955f658b1e02949555c212e0af501abca60ded
• Mozregression points out bug 1602195

Notes

• Firefox 73.0 RC2 (20200207001703) is not affected
• Attached a screenshot with the issue.
• I think this is not the same as bug 1605842.

The steps don't include showing a notification so I'm confused how this is different from bug 1605842; are you sure about this regression window? I don't see how bug 1602195 could have broken this...

(In reply to :Gijs (he/him) from comment #1)

The steps don't include showing a notification so I'm confused how this is different from bug 1605842; are you sure about this regression window? I don't see how bug 1602195 could have broken this...

The thing is if I open a build from the date 2019-12-24 (when bug 1605842 was logged) "Pause notifications until Nightly restarts" checkbox is shown when the build is started, without even generating a notification. The same thing on the good builds, the checkbox is present until Firefox 74.0a1 (20200106215403).

Beginning with Firefox 74.0a1 (20200107215758) and on today's latest Nightly, for example, there are no "Pause notifications until Nightly restarts" checkbox even if I generate push notifications. Am I doing something wrong here? I tried using https://serviceworke.rs website and "Push Payload"/"Push Simple" options. Or maybe there is another way to generate them that makes the "Pause notifications until Nightly restarts" checkbox appear?

Anyway, I redid the regression range and I get the same push log as before: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=25ec03d2ae24ec7e5f50bf959240694dbd4a30ec&tochange=f0955f658b1e02949555c212e0af501abca60ded.

If there is anything I can help with please let me know. Thank's!

Gijs, can you comment on comment 2? Sounds like this might be valid vs. a dupe of bug 1605842. (If you're sure it's a dupe anyway, please dupe it over!)

I think this only happens when we use the system notification framework on Windows, which is nightly-only right now. Alexandru, can you doublecheck you can't repro on beta 74?

Still trying to figure out what is going on here; the regression range is... odd. But there's definitely an issue here.

Didn't mean to clear my ni

(In reply to :Gijs (he/him) from comment #4)

I think this only happens when we use the system notification framework on Windows, which is nightly-only right now. Alexandru, can you doublecheck you can't repro on beta 74?

Still trying to figure out what is going on here; the regression range is... odd. But there's definitely an issue here.

Hello! Tried on 74.0b2 (20200211200559) and it seems that this is unaffected.

Regarding the regression range... I don't know why I get these results... maybe something is messing with mozregression from my system.. I tried with both GUI and cmd and I still get the same results. And on separate machines too. I downloaded the builds manually and still got the same results, at least on affected/unaffected days, attaching it here, for a wider regression range.
Last good revision: e6427fac5ee8d1d87fb78e917781e85dda119a81 (2020-01-06)
First bad revision: e728bf01a2b60414e18ac3abed8af55d5ab35924 (2020-01-07)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e6427fac5ee8d1d87fb78e917781e85dda119a81&tochange=e728bf01a2b60414e18ac3abed8af55d5ab35924

I did notice that on the first bad (e728bf01a2b60414e18ac3abed8af55d5ab35924 (2020-01-07)) build the items from about:preferences#privacy are strangely arranged. If more information is needed please let me know. Thank's!

(In reply to Alexandru Trif, QA [:atrif] from comment #6)

(In reply to :Gijs (he/him) from comment #4)

I think this only happens when we use the system notification framework on Windows, which is nightly-only right now. Alexandru, can you doublecheck you can't repro on beta 74?

Still trying to figure out what is going on here; the regression range is... odd. But there's definitely an issue here.

Hello! Tried on 74.0b2 (20200211200559) and it seems that this is unaffected.

Thanks for checking.

Regarding the regression range... I don't know why I get these results... maybe something is messing with mozregression from my system.. I tried with both GUI and cmd and I still get the same results.

Yeah, sorry, I should have clarified - I also checked the regression range and I see the same thing, so I think it's correct. I just don't know why it breaks. Yet. Needed to do a full (rather than artifact) windows build, going to debug that now...

OK, I'm a little lost here. I can reproduce on a local build, but backing out the changes from the regression range doesn't fix my local build.

Fundamentally, what I think happened before/after is that the alert service's mBackend used to be null, so we fall back on the XUL alert service which has the pause checkbox because it has manual do-not-disturb handling. And now, somehow, mBackend is not null and so that doesn't happen - the do not disturb setting from the OS will be honoured instead, AIUI, so we don't show the checkbox. Manually showing an alert doesn't change this. But I sort of think that was supposed to be what happened when the Windows system backend was in use anyway, so perhaps this just means something got fixed that was broken? But I don't know what that something is (ie why was mBackend null before?), or why we didn't notice it was broken, and I have no idea how it is related to bug 1602195 (though I guess it has something to do with taskbar group IDs and showing notifications, or something?) ... Matt, can you help shed some light?

(In reply to :Gijs (he/him) from comment #8)

OK, I'm a little lost here. I can reproduce on a local build, but backing out the changes from the regression range doesn't fix my local build.

Fundamentally, what I think happened before/after is that the alert service's mBackend used to be null, so we fall back on the XUL alert service which has the pause checkbox because it has manual do-not-disturb handling. And now, somehow, mBackend is not null and so that doesn't happen - the do not disturb setting from the OS will be honoured instead, AIUI, so we don't show the checkbox. Manually showing an alert doesn't change this. But I sort of think that was supposed to be what happened when the Windows system backend was in use anyway, so perhaps this just means something got fixed that was broken? But I don't know what that something is (ie why was mBackend null before?), or why we didn't notice it was broken, and I have no idea how it is related to bug 1602195 (though I guess it has something to do with taskbar group IDs and showing notifications, or something?) ... Matt, can you help shed some light?

On non-installed builds we didn't used to use the system backend on Windows because there was no explicit group ID defined for the application. I changed that in bug 1602195 so now development builds behave the same as installed builds in this respect. Perhaps that is the confusion here?

This should be "fixed" now that we re-disabled Windows native notification support in bug 1614274.