Closed Bug 1327486 Opened 8 years ago Closed 7 years ago

Push notifications notification doesn't hide consistently when I switch to another tab and back

Categories

(Core :: DOM: Push Subscriptions, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: arni2033, Unassigned)

Details

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
I tested 2 scenarios and found contradiction

>>>
STR_1:
1. Open https://rns.online/ in a new tab (middle-click the link)
2. Open https://life.ru/ in a new tab (middle-click the link), wait until all tabs load
3. Click on tab from Step 1
4. Click on tab from Step 2
5. Click on tab from Step 1
6. Click on tab from Step 2

AR:  In steps 5 and 6 push notifications button is visible in urlbar


STR_2:
1. Open https://rns.online/ in a new tab (middle-click the link), wait until it loads
2. Click on tab from Step 1
3. Click on tab with this bug report
4. Click on tab from Step 1

AR:  In Step 4 push notifications button isn't visible in urlbar


Expected result:  Either X or Y
 X) Push notifications should work just like any other permission popup (geolocation, camera access),
    i.e. actual result in STR_1 is good, and actual result in STR_2 is incorrect.
    In STR_2 notification button should be displayed in urlbar
 Y) If developers have decided to hide push notification button completely when user dismisses
    panel (switching to other tab=dismiss), then STR_1 is incorrect, and STR_2 is good.
    In STR_1 notification button shouldn't be displayed in urlbar in Steps 5 and 6

Notes:
1) Any other type of logic seems complicated, but if push notifications panel follows some complicated
   logic, at least tell me that logic before closing the bug
2) Actually, I see some strangeness in other popups too, because result in STR_1 isn't completely
   expected, because, as I've noticed, clicking outside of panel = dismiss.
   I can even see how panel starting to close before I "completely" switch to another tab.
   I can't tell if there's some logic behind that behavior or nobody really cared about how it works,
   but (X) could at least make permissions consistent - that's already a step forward IMO.
No longer blocks: 1277113
Component: Untriaged → Activity Streams: General
Component: Activity Streams: General → General
Component: General → DOM: Push Notifications
Product: Firefox → Core
(In reply to arni2033 from comment #0)
> >>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
> I tested 2 scenarios and found contradiction
> 
> >>>
> STR_1:
> 1. Open https://rns.online/ in a new tab (middle-click the link)
> 2. Open https://life.ru/ in a new tab (middle-click the link), wait until
> all tabs load
> 3. Click on tab from Step 1
> 4. Click on tab from Step 2
> 5. Click on tab from Step 1
> 6. Click on tab from Step 2
> 
> AR:  In steps 5 and 6 push notifications button is visible in urlbar
> 
> 

I did see this AR which is working as expected I'd say.

> STR_2:
> 1. Open https://rns.online/ in a new tab (middle-click the link), wait until
> it loads
> 2. Click on tab from Step 1
> 3. Click on tab with this bug report
> 4. Click on tab from Step 1
> 
> AR:  In Step 4 push notifications button isn't visible in urlbar
> 

I didn't manage to see reporter's AR here. Instead, I did see the push notifications button as STR1, on Nightly 53 on MAC.

> 
> Expected result:  Either X or Y
>  X) Push notifications should work just like any other permission popup
> (geolocation, camera access),
>     i.e. actual result in STR_1 is good, and actual result in STR_2 is
> incorrect.
>     In STR_2 notification button should be displayed in urlbar
>  Y) If developers have decided to hide push notification button completely
> when user dismisses
>     panel (switching to other tab=dismiss), then STR_1 is incorrect, and
> STR_2 is good.
>     In STR_1 notification button shouldn't be displayed in urlbar in Steps 5
> and 6
> 
> Notes:
> 1) Any other type of logic seems complicated, but if push notifications
> panel follows some complicated
>    logic, at least tell me that logic before closing the bug
> 2) Actually, I see some strangeness in other popups too, because result in
> STR_1 isn't completely
>    expected, because, as I've noticed, clicking outside of panel = dismiss.
>    I can even see how panel starting to close before I "completely" switch
> to another tab.
>    I can't tell if there's some logic behind that behavior or nobody really
> cared about how it works,
>    but (X) could at least make permissions consistent - that's already a
> step forward IMO.
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #1)
> (In reply to arni2033 from comment #0)
> > >>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
> > I tested 2 scenarios and found contradiction
> > 
> > >>>
> > STR_1:
> > 1. Open https://rns.online/ in a new tab (middle-click the link)
> > 2. Open https://life.ru/ in a new tab (middle-click the link), wait until
> > all tabs load
> > 3. Click on tab from Step 1
> > 4. Click on tab from Step 2
> > 5. Click on tab from Step 1
> > 6. Click on tab from Step 2
> > 
> > AR:  In steps 5 and 6 push notifications button is visible in urlbar
> > 
> > 
> 
> I did see this AR which is working as expected I'd say.
> 
> > STR_2:
> > 1. Open https://rns.online/ in a new tab (middle-click the link), wait until
> > it loads
> > 2. Click on tab from Step 1
> > 3. Click on tab with this bug report
> > 4. Click on tab from Step 1
> > 
> > AR:  In Step 4 push notifications button isn't visible in urlbar
> > 
> 
> I didn't manage to see reporter's AR here. Instead, I did see the push
> notifications button as STR1, on Nightly 53 on MAC.
> 

I got the same result on Firefox 50 on Win10, i.e. I cannot reproduce this.
I'm not sure if I understand correctly, but it sounds like arni2033 is talking about the permission doorhanger. If so, the push permission doorhanger is special. Unlike the others, it's not minimized to the URL bar if you dismiss it by clicking outside the doorhanger, or switching to a new tab. This was a deliberate decision made in bug 1259148, based on partner feedback.

The new doorhanger implemented in bug 1282768 changes this, too. Clicking outside the doorhanger doesn't minimize it anymore; you need to make a choice before it's dismissed.

Closing as WONTFIX based on that, but please reopen if I've misunderstood the issue.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.