Closed Bug 1186181 Opened 9 years ago Closed 5 years ago

transition from shield to no shield creates weird transition

Categories

(Firefox :: Theme, defect, P3)

defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox42 --- affected

People

(Reporter: agrigas, Unassigned)

References

Details

(Whiteboard: [fxprivacy])

Attachments

(2 files)

Look at this clip:
https://www.dropbox.com/s/p665j08motf1qwt/1567571A-UserTesting.mp4?dl=0

When user is on page with trackers and types in url of page without trackers - the site identity icon is delayed in transitioning back to the far most right position in the url bar.
Flags: firefox-backlog?
Depends on: 1186925
Flags: firefox-backlog? → firefox-backlog+
Priority: -- → P3
Depends on: 1184312
No longer depends on: 1186925
Attached video animation-vid.mp4
video of the animation
Blocks: 1188565
Flags: qe-verify?
Priority: P3 → P1
STR:

Open PB Window
Navigate to youtube.com (or some site that triggers shield AND a plugin notification)
Navigate to wikipedia.org, but keep your mouse on the URL bar
Notice a small white gap to the left of the lock
When you move your mouse away from the URL bar the gap goes away
Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED
Iteration: --- → 43.2 - Sep 7
This actually seems to be fixed now that the shield disappears once you start typing into the URL bar.

Here's another test page that triggers the shield: http://www.flashgames247.com/play/17012.html
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Hi Brian, can you set this bug to qe-verify- or qe-verify+
Flags: needinfo?(bgrinstead)
qe-verify+ but just to confirm that the STR in Comment 2 aren't happening anymore (it used to lead to a result that can be seen in the video in Comment 1).
Flags: qe-verify?
Flags: qe-verify+
Flags: needinfo?(bgrinstead)
STR in comment 2 still reproducible on 43.0a1 (2015-09-09), 42.0a2 (2015-09-10) Win 7.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Iteration: 43.2 - Sep 7 → 43.3 - Sep 21
Flags: firefox-backlog+
Assignee: bgrinstead → nobody
Iteration: 43.3 - Sep 21 → ---
Status: REOPENED → NEW
Priority: P1 → P2
Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED
Iteration: --- → 44.1 - Oct 5
Priority: P2 → P1
Paolo, I've tracked this down to the transition delay here added in Bug 1196313: https://dxr.mozilla.org/mozilla-central/rev/5abe3c4deab94270440422c850bbeaf512b1f38d/browser/themes/shared/identity-block/identity-block.inc.css?offset=0#67

Basically, there are cases where the forward button isn't visible at all but we still end up setting the 100s delay before reducing the padding in the identity block.  From my local tests, things work just fine if I remove the transition and transition-delay for padding-left/padding-right on this element.

Specific STR:
* Open new tab
* Go to http://www.flashgames247.com/play/17012.html
* Wait for both plugin icon and shield to load
* Click on URL bar and keep mouse there
* Enter wikipedia.com
* Notice that there is no forward button but there is extra spacing to the left of the identity block until you move the mouse away.

Any guidance?  I'll send a review request that removes the transition, but I'm sure it was added for a reason so let me know how you think we should proceed.
Blocks: 1196313
Flags: needinfo?(paolo.mozmail)
Bug 1186181 - Don't do transitions for padding on identity box;r=paolo
Attachment #8666265 - Flags: review?(paolo.mozmail)
Comment on attachment 8666265 [details]
MozReview Request: Bug 1186181 - Don't do transitions for padding on identity box;r=paolo

This code is still needed. STR:

- load data:,1
- load data:,2 in the same tab
- move the mouse over the location bar
- press Alt + Arrow Left
- press Alt + Arrow Right
Attachment #8666265 - Flags: review?(paolo.mozmail) → review-
(In reply to Dão Gottwald [:dao] from comment #9)
> Comment on attachment 8666265 [details]
> MozReview Request: Bug 1186181 - Don't do transitions for padding on
> identity box;r=paolo
> 
> This code is still needed. STR:
> 
> - load data:,1
> - load data:,2 in the same tab
> - move the mouse over the location bar
> - press Alt + Arrow Left
> - press Alt + Arrow Right

Is there a way to determine if the forward button is actually visible (i.e. [disabled] and still waiting for a transition-delay to fire vs [disabled] and it was never visible at all)?
Flags: needinfo?(dao)
Personally, if we could replace the complex CSS selectors and transition-delay (which require some repetition in different places and files) with a bit of JavaScript I would be in favor of doing it.

On the other hand, if we refactor the notification icons (including the plugin icon) to be to the right of the new "i" icon instead of inside the dedicated notification area, this issue here would become a lot less frequent. We might even be able to remove a lot of this CSS code if we move all notifications to the new style, which is however a long term goal.

I wouldn't spend a lot of time on this issue if the fix is not very easy.
Flags: needinfo?(paolo.mozmail)
(In reply to Brian Grinstead [:bgrins] from comment #10)
> (In reply to Dão Gottwald [:dao] from comment #9)
> > Comment on attachment 8666265 [details]
> > MozReview Request: Bug 1186181 - Don't do transitions for padding on
> > identity box;r=paolo
> > 
> > This code is still needed. STR:
> > 
> > - load data:,1
> > - load data:,2 in the same tab
> > - move the mouse over the location bar
> > - press Alt + Arrow Left
> > - press Alt + Arrow Right
> 
> Is there a way to determine if the forward button is actually visible (i.e.
> [disabled] and still waiting for a transition-delay to fire vs [disabled]
> and it was never visible at all)?

Not sure, but I suspect not.
Flags: needinfo?(dao)
As discussed with Paolo, this may not be an issue after the 'i' icon grouping and it looks like it's going to be time consuming to fix now for a small benefit.  So, unassigning for now and we can revisit after the ID block changes
Assignee: bgrinstead → nobody
Status: ASSIGNED → NEW
Iteration: 44.1 - Oct 5 → ---
Depends on: 1188118
Priority: P1 → P2
Blocks: 1216897
No longer blocks: 1188565
Priority: P2 → P3
See Also: → 1235838
See Also: → 1238390
Component: General → Theme
Status: NEW → RESOLVED
Closed: 9 years ago5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: