Open Bug 1387142 Opened 7 years ago Updated 21 days ago

Suppress window animation for New Window

Categories

(Firefox :: General, defect, P4)

Desktop
All
defect

Tracking

()

Performance Impact low

People

(Reporter: aflorinescu, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf:animation, perf:responsiveness)

[Environment:]
Windows, MacOSX

[Description:]
The same change as in bug 1362103 should be applied to the cases in which new window is created.

[Steps:]
1.   Open FF.
2.   File/New Window.
2.1  File/New Private Window.
2.2  File/New Non E10s Window. 
2.3  Open a new tab and drag and drop into a new window (similar to step 1)
2.4  Drag the tab from the step 2.3 back into another window.


[Actual Result:]
The window animation is visible for all STR scenarios.

[Expected Result:]
I believe applying a fix similar to bug 1362103 and removing the window animation for all STR will be seen as FF performance improvement.
Flags: qe-verify+
Priority: -- → P2
Whiteboard: [photon-performance][triage] → [photon-performance]
I think this needs UX input. Philipp, in which case do we want to keep this window opening animation and in which cases do we want to avoid it?
Flags: needinfo?(philipp)
The distinction is simple whether the window will be opened in maximized mode (no animation) or window mode (animation). This is the same behavior as Chrome and Edge.
Bug 1362103 added the first window (regardless of mode) to the list. I wasn't aware of this, but it makes sense since we are really focused on bringing down perceived startup time.

I'm not sure how big the wins in other cases would be. There is something to be said for keeping OS animations most of the time to be consistent with the environment. So I think the current behavior strikes a pretty good balance.
Flags: needinfo?(philipp)
(In reply to Adrian Florinescu [:AdrianSV] from comment #0)

> [Steps:]
> 1.   Open FF.
> 2.   File/New Window.
> 2.1  File/New Private Window.
> 2.2  File/New Non E10s Window. 

As Philipp said, we want to suppress animations only when the new window will be maximized, and we open the new window maximized if the current window is maximized. This is already the implemented behavior, but during my testing it didn't work reliably. Sometimes I got animations even for maximized windows. I suspect window.windowState is sometimes not giving the correct value at http://searchfox.org/mozilla-central/rev/b258e6864ee3e809d40982bc5d0d5aff66a20780/browser/base/content/browser.js#4192

I haven't been able to find reliable steps to reproduce unfortunately. If someone can find them, I would appreciate it :-).

> 2.3  Open a new tab and drag and drop into a new window (similar to step 1)
> 2.4  Drag the tab from the step 2.3 back into another window.

I filed a separate bug to dig into this, and remove tab drag&drop flickering: bug 1391704
Priority: P2 → P3
Whiteboard: [photon-performance] → [reserve-photon-performance]
Priority: P3 → P4
Whiteboard: [reserve-photon-performance] → [fxperf]
P3 given this seems to reproduce only intermittently.
Whiteboard: [fxperf] → [fxperf:p3
Whiteboard: [fxperf:p3 → [fxperf:p3]
Severity: normal → S3

The Performance Impact Calculator has determined this bug's performance impact to be low. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: [x] Windows [x] macOS [x] Linux
Impact on browser: Causes noticeable jank
Configuration: Rare
[x] Affects animation smoothness

Performance Impact: --- → low
OS: Unspecified → All
Hardware: Unspecified → Desktop
Whiteboard: [fxperf:p3]
You need to log in before you can comment on or make changes to this bug.