1278549 - First suggestion twitches when I edit a long string if there're >=3 toolbarbuttons before urlbar

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, defect, P3)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
STR:
1. Move zoom level toolbarbutton [- | 100% | +] before urlbar
2. Open new tab, type as many letters "m" in urlbar as possible without overflow in 1st suggestion
3. Type "i" ten times
4.(bonus) Type "Search with Google", then type "m" 20 times 
5.(bonus) Keep holding button "M" for 10 seconds. Then keep holding Backspace for 10 seconds

AR:
 Text in the 1st suggestion twitches to not-overflow state and back (similar to bug 1266375).
 Step 4:  text label "Search with Google" is briefly pushed outside the visible part of suggestion
 Step 5:  text label "Search with Google" is pushed outside the visible part of suggestion

ER:  
 No extra text twitching. Text label "Search with Google" should be visible

This is regression from bug 1266375. Regression range:
> https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=6bbcf33e1a709cc6bd9a9ab73e303093fc748239&tochange=597390d44c49cb5c89260feb4f5e1e6ef2eef15c

Comment 1

[arni2033]

Attachment: screencast 1 (bug 1278549) - First suggestion twitches.webm

STR in comment 0 was written for screen resolution 1366x768. For 1280x1024 I recommend another Step 2:

2. Type "nnnn", then type as many letters "m" in urlbar as possible without overflow in 1st suggestion

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Panos, could you please update the status of 48, 49, 50 as wontfix/fix-wanted/affected, depending on how much we need the fix in any of these releases, so that the triage group knows what the plan is.

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

I'm on vacation, so I'll defer to Marco.

Comment 4

[Marco Bonardo [:mak]]

This is showing a race condition in the urlbar content resizing code, that sooner or later should be investigated, but it requires specially forged steps that are quite unlikely for a common user to be executed.
I don't think it's critical to fix this soon, I assume fix-optional means we'll take a fix if possible, but we won't specifically schedule time to fix this.

Off-hand I don't think this should be tracked at all, it's one of the many UI annoyances we have around when contents go mad (like a page suggesting hundreds of search engines for example).

Comment 5

[arni2033]

(In reply to Marco Bonardo [::mak] from comment #4)
> but it requires specially forged steps that are quite unlikely for a common user
That's wrong. Why does everybody always says the same wrong thing without even reading STR?
STR in comment 0 require specially forged steps to demonstrate all cases of this bug.
The bug itself requires simply typing text in urlbar.

Comment 6

[Marco Bonardo [:mak]]

(In reply to arni2033 from comment #5)
> The bug itself requires simply typing text in urlbar.

A lot of text actually, so much that it's unlikely to happen.
We must prioritize things that users are more likely to hit, it's unlikely a user is manually typing hundreds of chars, plus the visual glitch in such a case doesn't really break any kind of workflow, it's just a polish thing.
Since it's harmless and requires a non common action, I don't see why it should be a priority.

Comment 7

[Marco Bonardo [:mak]]

WFM in Nightly