Notification rectangle is completely gray if mouse was placed over another application when notification appeared AND mouse was placed in the notification area

RESOLVED FIXED in Firefox 51

Status

()

defect
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: arni2033, Assigned: jaws)

Tracking

(Depends on 1 bug, {regression})

27 Branch
mozilla51
Unspecified
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox51 fixed)

Details

Attachments

(3 attachments)

(Tested on Windows 7 with Fx39,41,42 )

STR:
1. Open testpage; change the firefox window size so that the area (rectangle) where notification appears, was not placed over any current firefox windows
2. Click "Start countdown" and move mouse in the notification area before the countdown is finished

Result:
Gray reactangle appeared instead of notification (actually if you move mouse away from notification area, then animation will continue and you'll actually see the notification)
Expectations:
Normal notification should've appeared, regardless of mouse position
I can reproduce the problem
Status: UNCONFIRMED → NEW
Ever confirmed: true
And this is a regression since Firefox27.
Keywords: regression
Pushlog:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=184a0076278b&tochange=220ce292a894

Suspect:
	51d151978c2b	Matthew Noorenberghe — Bug 888380 - Alert service notifications shouldn't disappear when hovered. r=jaws
Blocks: 888380
Component: Untriaged → Notifications and Alerts
Flags: needinfo?(MattN+bmo)
OS: Unspecified → Windows 7
Product: Firefox → Toolkit
Version: Trunk → 27 Branch
I'm pretty sure that there is already a bug on file for this. But to fix this we need to let the notification fade in before stopping the animation.
Whiteboard: [dupeme]
Also, I think it's a good idea to show the actual notification, not the gray rectangle, if animation is stopped in its end (user hovered mouse over notification just before it disappeared). In this case, notification is also just a gray rectangle.
Please tell me if this deserves another bug report OR create it yourself if there's no dupe for this
I think this is fixed now on Fx44+, do you agree?
Flags: needinfo?(MattN+bmo) → needinfo?(arni2033)
(In reply to Matthew N. [:MattN] from comment #8)
> I think this is fixed now on Fx44+, do you agree?
This is not fixed at all (including comment 7). Now I don't see gray rectangle, but
the original bug was that notification was unreadable with almost zero opacity. In more detail:
1) opacity 0->1 transition didn't finish
   when I hovered mouse over notification in the start of the transition
2) opacity 1->0 transition didn't came back to 1
   when I hovered mouse over notification in the end of the transition (comment 7)

I can provide screencast of each behavior via my dropbox.
Flags: needinfo?(arni2033)
Yeah I don't suspect that this is fixed. The grey box should no longer be there as the notifications are now transparent, but this just means that the notification will not fade-in until the mouse is moved. We likely need to adjust the CSS rule that pauses the animation so it doesn't apply until the notification has made it to the second step of the CSS Animation (though I don't think the CSS Animation spec has anything like this).
Whiteboard: [dupeme]
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Comment on attachment 8791649 [details]
Bug 1184790 - Force notifications to have opacity:1 when hovered to make sure that we show a readable notification during the intro/exit animation of the notification if the user has their mouse in the area.

https://reviewboard.mozilla.org/r/79020/#review77612

::: toolkit/themes/shared/alert-common.css:29
(Diff revision 1)
>  #alertBox[animate][closing] {
>    animation-duration: .6s;
>    animation-name: alert-closing-animation;
>  }
>  
> +#alertBox[animate]:not([clicked]):not([closing]):hover {

OK, I see this is the same selector as the one used for `animation-play-state: paused;`. LGTM

::: toolkit/themes/shared/alert-common.css:30
(Diff revision 1)
>    animation-duration: .6s;
>    animation-name: alert-closing-animation;
>  }
>  
> +#alertBox[animate]:not([clicked]):not([closing]):hover {
> +  /* !important is necesary because CSS animations have highest

Spelling nit: necessary
Attachment #8791649 - Flags: review+
Attachment #8791649 - Flags: review?(gijskruitbosch+bugs)
@ Jared Wein:
Could you please check if this patch causes the following bugs? (+ are they real bugs)

1) When push notification appears below moving mouse pointer,it appears w/o opacity fade-in transition
2) When I hover mouse over notification in the end of transition, then move mouse away,
   notification disappears w/o opacity fade-out transition.
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5ac7de633609
Force notifications to have opacity:1 when hovered to make sure that we show a readable notification during the intro/exit animation of the notification if the user has their mouse in the area. r=MattN
(In reply to arni2033 from comment #14)
> @ Jared Wein:
> Could you please check if this patch causes the following bugs? (+ are they
> real bugs)
> 
> 1) When push notification appears below moving mouse pointer,it appears w/o
> opacity fade-in transition
> 2) When I hover mouse over notification in the end of transition, then move
> mouse away,
>    notification disappears w/o opacity fade-out transition.

Yes the patch causes both of those behaviors. Whether they are a bug or not is up to opinion.

How would you like this to behave? I am not sure if we can transition do a transition here and I'm also not sure if we can delay or restart the notification timeout.
Flags: needinfo?(arni2033)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #16)
> Yes the patch causes both of those behaviors. Whether they are a bug or not is up to opinion.
"Sometimes push notification appears smoothly, sometimes it just shows up immediately
 I'm a simple user, and can't understand, why it's doing that, but I'd like it to be less random"

> How would you like this to behave? I am not sure if we can transition do a transition here and
> I'm also not sure if we can delay or restart the notification timeout.
It's hard to describe with words (not mock-ups), but I have no time for mock-ups now.
I have 2 alternative expectations

A) Behavior currently maintained by Mozilla, but w/o blinking
- When notification appears, it should go from opacity:0 to opacity:1, and nothing should interfere
- Special variable S invisible in UI should be set to 0
- Every millisecond when mouse is placed outside of notification, S should be increased by 1
- When S becomes greater than predefined timeout T, notification switches to "fade out" mode.
-- In "fade out" mode notification should smoothly go from current opacity to opacity:0
-- If mouse is hovered above notification, it should go from current opacity to opacity:1,
   with the same speed (backwards animation function), and stop at opacity:1
-- When notification reaches opacity:0, it should be deleted

B) Best UX ever. Notification hides after T milliseconds after the last interaction
- When notification appears, it should go from opacity:0 to opacity:1, and nothing should interfere
- Special variable S invisible in UI should be set to 0
- Every millisecond when mouse is placed outside of notification, S should be increased by 1
* When mouse is placed above notification, S should be set to 0, i.e. reset (!)
- When S becomes greater than predefined timeout T, notification switches to "fade out" mode.
-- In "fade out" mode notification should smoothly go from current opacity to opacity:0
** If mouse is hovered above notification, S should be set to 0.
   Notification should go from current opacity to opacity:1, with the same speed (backwards
   animation function), and stop at opacity:1. Nothing should interfere
   When notification reaches opacity:1, it should switch to normal (not "fade out") mode.
-- When notification reaches opacity:0, it should be deleted


This is how I expect such widget to work, implementation may be different.
«*»s represent differences between (A) and (B). «--»s represent rules of "fade out" mode.
https://hg.mozilla.org/mozilla-central/rev/5ac7de633609
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
(In reply to arni2033 from comment #18)

I agree with both of your recommendations. I have tried to implement A but don't see a way how to, and B I think might be possible but would require some extra JavaScript code. Can you file a bug for option B? It's not high enough on my priority list right now for me to work on it but maybe I'll have time in the future or someone else can get to it sooner.
Flags: needinfo?(arni2033)
Depends on: 1327871
Flags: needinfo?(arni2033)
You need to log in before you can comment on or make changes to this bug.