Suppress window animation for New Window

NEW
Unassigned

Status

()

defect
P4
normal
2 years ago
Last year

People

(Reporter: adrian_sv, Unassigned)

Tracking

(Blocks 1 bug)

unspecified
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxperf:p3])

[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]

Comment 4

Last year
P3 given this seems to reproduce only intermittently.
Whiteboard: [fxperf] → [fxperf:p3

Updated

Last year
Whiteboard: [fxperf:p3 → [fxperf:p3]
You need to log in before you can comment on or make changes to this bug.