Closed Bug 1278549 Opened 3 years ago Closed 3 months ago

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

Categories

(Firefox :: Address Bar, defect, P3)

48 Branch
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox47 --- unaffected
firefox48 --- fix-optional
firefox49 --- fix-optional
firefox50 --- fix-optional

People

(Reporter: arni2033, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [fxsearch])

Attachments

(1 file)

>>>   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
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
Priority: -- → P3
Whiteboard: [fxsearch]
Version: unspecified → 48 Branch
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.
Flags: needinfo?(past)
I'm on vacation, so I'll defer to Marco.
Flags: needinfo?(past) → needinfo?(mak77)
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).
(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.
(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.

WFM in Nightly

Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.