1372535 - Remove drag space at the start of the tab strip when maximezing window is not smooth

Status: VERIFIED FIXED

(Firefox :: Theme, defect, P1)

Description

[Brindusa Tot, Desktop QA]

Attachment: Maximize on Mac.mp4

[Affected versions]:
- Nightly 56.0a1
 
[Affected platforms]:
- Mac OS X 10.12
 
[Steps to reproduce]:
1. Launch Nightly, make sure that window is not maximized.
2. Maximize window.
 
[Expected result]:
- The window is maximized and the drag space at the start of the tab strip should be smoothly removed.
 
[Actual result]:
- The window is maximized and the drag space at the start of the tab strip is removed but not smooth (after the page is maximized the tab strip jumps a little on the left side of the tabs bar)
 
[Additional notes]:
- Same scenarios occur if the page is maximized and user resize it.
- If the user tries to go to full screen, then the drag space at the start of the tab strip is removed in two steps. (see screencast)
 - This bug is reproducible only on Mac OS X OS-es.

Comment 1

[Dão Gottwald [:dao]]

My naive interpretation of this is that we update the sizemode attribute too late, after the resize animation. Can we do this earlier?

Comment 2

[Johann Hofmann [:johannh]]

We might still need an animation, since it would jump even if we set the sizemode attribute earlier, right? It may be less noticeable because everything is kinda moving in that moment but it wouldn't be smooth.

Comment 3

[Markus Stange [:mstange]]

(In reply to Dão Gottwald [::dao] from comment #1)
> My naive interpretation of this is that we update the sizemode attribute too
> late, after the resize animation. Can we do this earlier?

Not easily, no. The hard part would be detecting when we've left the maximized state again.

I recommend not adjusting the drag space on Mac based on the "maximized" sizemode. It makes sense to adjust it in the fullscreen mode instead.

macOS doesn't really have a maximized mode; it has a "zoomed" mode which we treat as "maximized" sizemode, and it has a fullscreen mode. When you zoom a window, it's supposed to resize to its "natural" or "best" size, which is for most apps the smallest size that does not require scrolling. In Firefox we just say that filling the whole screen is our "best" size. But if a window is zoomed, you can still move it by dragging its title bar. For example, you may want to do that if you want to move it to a different screen.

Mac apps usually don't change their appearance at all if they enter the "zoomed" size. They only do that if you make the window fullscreen. The native full screen mode on Mac is much closer to the maximized mode on Windows than the zoomed mode is.

Recent versions of macOS have changed the default action of the green window button to be fullscreen instead of zoom. You can now only zoom windows by double clicking the title bar or clicking the green button while holding Alt.

Comment 4

[Dão Gottwald [:dao]]

Attachment: Bug 1372535 - On Mac, remove the window drag space when sizemode!=fullscreen rather than sizemode==maximized.

macOS doesn't really have a maximized mode; it has a "zoomed" mode which we treat as "maximized" sizemode, and it has a fullscreen mode. When you zoom a window, it's supposed to resize to its "natural" or "best" size, which is for most apps the smallest size that does not require scrolling. In Firefox we just say that filling the whole screen is our "best" size. But if a window is zoomed, you can still move it by dragging its title bar. For example, you may want to do that if you want to move it to a different screen.

Mac apps usually don't change their appearance at all if they enter the "zoomed" size. They only do that if you make the window fullscreen. The native full screen mode on Mac is much closer to the maximized mode on Windows than the zoomed mode is.

Recent versions of macOS have changed the default action of the green window button to be fullscreen instead of zoom. You can now only zoom windows by double clicking the title bar or clicking the green button while holding Alt.

Review commit: https://reviewboard.mozilla.org/r/148994/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/148994/

Comment 5

[Johann Hofmann [:johannh]]

Comment on attachment 8877532 [details]
Bug 1372535 - On Mac, remove the window drag space when sizemode!=fullscreen rather than sizemode==maximized.

https://reviewboard.mozilla.org/r/148994/#review153902

I'm fine with this patch, but it doesn't fix the problem with the double-jumping tabs when switching to fullscreen and therefore wouldn't resolve this bug. I really think this should have its own animation instead. We can't prevent jumping (though we could try to get rid of the double jumping), so animating the movement sounds best to me.

Comment 6

[Dão Gottwald [:dao]]

(In reply to Johann Hofmann [:johannh] from comment #5)
> Comment on attachment 8877532 [details]
> Bug 1372535 - On Mac, remove the window drag space when sizemode!=fullscreen
> rather than sizemode==maximized.
> 
> https://reviewboard.mozilla.org/r/148994/#review153902
> 
> I'm fine with this patch, but it doesn't fix the problem with the
> double-jumping tabs when switching to fullscreen and therefore wouldn't
> resolve this bug. I really think this should have its own animation instead.
> We can't prevent jumping (though we could try to get rid of the double
> jumping), so animating the movement sounds best to me.

This doesn't really make sense to me. As far as I can tell, there's no such issue on Windows where sizemode changes are animated too. Surely we don't want to add our own animation there as it would make the whole transition more complex and heavyweight.

(In reply to Markus Stange [:mstange] from comment #3)
> (In reply to Dão Gottwald [::dao] from comment #1)
> > My naive interpretation of this is that we update the sizemode attribute too
> > late, after the resize animation. Can we do this earlier?
> 
> Not easily, no. The hard part would be detecting when we've left the
> maximized state again.

Is this an issue for the fullscreen state too or can we update the attribute earlier there?

Comment 7

[Markus Stange [:mstange]]

(In reply to Johann Hofmann [:johannh] from comment #5)
> I'm fine with this patch, but it doesn't fix the problem with the
> double-jumping tabs when switching to fullscreen and therefore wouldn't
> resolve this bug.

It sounds like a completely different bug though.
The problem reported in this bug is: Zooming a window first animates the window size and then adjusts the drag space in one discrete step. This problem would be solved by not adjusting the drag space on zooming.
The problem that's now being brought up is: Making a window fullscreen animates to the fullscreen state and then adjusts the drag space in *two* discrete steps. That's a legitimate problem but I think it should be fixed in a different bug.

> I really think this should have its own animation instead.
> We can't prevent jumping (though we could try to get rid of the double
> jumping), so animating the movement sounds best to me.

The system provides us with a cross-fade animation during the fullscreen transition; it fades the non-fullscreen window to the fullscreen window. We need to make sure that this fullscreen state rendering already has the adjustment applied. The problem is that we only apply it after the transition has completed. But if we apply it sooner, then I think the system-provided cross-fade animation is all we need.

Comment 8

[Johann Hofmann [:johannh]]

Comment on attachment 8877532 [details]
Bug 1372535 - On Mac, remove the window drag space when sizemode!=fullscreen rather than sizemode==maximized.

https://reviewboard.mozilla.org/r/148994/#review154404

Thanks for opening bug 1373581. This patch should solve the maximize issues on OSX.

Comment 9

[Johann Hofmann [:johannh]]

Marking 55 as unaffected since the Photon theme is not enabled in Beta or Release.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3ac1889ff773
On Mac, remove the window drag space when sizemode!=fullscreen rather than sizemode==maximized. r=johannh

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3ac1889ff773

Comment 12

[Sören Hentzschel]

Attachment: screenshot

Is this ticket the reason why there is a lot of empty space on the left side of the tab bar again since today's Nightly? It basically reverted bug 1369786 on macOS…

Comment 13

[Markus Stange [:mstange]]

Yes, that was the intention. If there's not unanimous agreement on this, maybe we should ask UX for advice.

Comment 14

[Sören Hentzschel]

I don't think it makes much sense to waste so much space if the window is maximized… The horizontal space is already very limited on usual monitors… But at least it should be consistent across platforms. Why should there be a difference between macOS and Windows?

Comment 15

[Markus Stange [:mstange]]

I think I answered that in comment 3.

Comment 16

[Sören Hentzschel]

It still does not make much sense in my opinion, because it does not make much sense to move the window if the browser window already fills the full window. Yes, moving a window to a different screen may be a use case. But that's no use case which only exisits on macOS, it does also exist on Windows. And I am pretty sure that most users *don't *use more than one screen so Firefox should not be optimized for the minority of users if it means a disadvantage for all other users.

Either it make sense to have a drag space in full sized windows, then you should do this on all platforms, or it does not make sense. But please don't introduce such big design inconsistencies across platforms…

As I already said the space of the tab bar is already very limited. And I don't know any other browser which waste the already limited space. Chrome does not, Safari does not. If you want a great OS integration please use Safari as reference because as Apple product it's the reference browser for macOS. Safari has a different tab bar and I don't say that you should use the same tab bar but the important thing is: Safari does not waste any space of the tab bar. I don't think that I am the only user with more than five open tabs at the same time, I really appreciate every available pixel of the tab bar…

I really think "maybe we should ask UX for advice" from comment 13 is what should be done. ;)

Comment 17

[Sören Hentzschel]

needinfo :shorlander because of comments 12 to 16. Could you please clarify if the current state for macOS should be kept or not? a) I don't see a reason to handle macOS different than Windows and b) it's a waste of space for users with a few more tabs. And c) there was already bug 1369786 to *remove* the empty space…

Regarding the "more than one screen" usecase: maybe it could be detected if there is more than one screen and keep the empty space in this case (but then on ALL platforms not only macOS!). But I doubt that most users use more than one screen so it should not be the default case…

Comment 18

[Stephen Horlander [:shorlander]]

(In reply to Sören Hentzschel from comment #17)
> needinfo :shorlander because of comments 12 to 16. Could you please clarify
> if the current state for macOS should be kept or not? a) I don't see a
> reason to handle macOS different than Windows and b) it's a waste of space
> for users with a few more tabs. And c) there was already bug 1369786 to
> *remove* the empty space…
> 
> Regarding the "more than one screen" usecase: maybe it could be detected if
> there is more than one screen and keep the empty space in this case (but
> then on ALL platforms not only macOS!). But I doubt that most users use more
> than one screen so it should not be the default case…

I am not sure I understand the question.

We should not have the drag-space when the window is: maximized, fullscreen, tablet mode is enabled or if the title bar is enabled.

On Windows 10 all of those options are possible.

On macOS there is no concept of a maximized window. All windows are always in window mode (and therefore more likely to be dragged) unless they are fullscreen.

Comment 19

[Sören Hentzschel]

Attachment: screenshot

I disagree that there is no concept of a maximized window on macOS. Maybe there is not such a concept from a technical point of view but from the user's point of view you can - of course - "maximize" the window. In fact I know more macOS users than Windows users and *all* of these use their browsers maximized, there are exactly zero exceptions. At the moment Firefox is the *only* browser wasting the space of the tab bar. Chrome does not, Safari does not, Opera does not not. And Firefox did this never before. It's not clear at all why Firefox 57+ should be the *only browser* wasting the space of the tab bar if the window is maximized.

Please look at the attached screenshot. This *is* a maximized windows, even if it's something different from a technical point of view. I don't have a second screen so the empty space in my screenshot does not make sense *at all*. There is no space on my windows to drag the window to another position without hiding parts of the window (and to hide parts of the window does not make sense). So there is *no reason* for a drag space.

Comment 20

[Stephen Horlander [:shorlander]]

Yes, you can make a window fill the entire screen on macOS. You can do this manually or sometimes with the Zoom function. But there is no expected mode difference, it's just a larger window.

We are making an intentional trade-off between some horizontal tab space for predictable/persistent drag space. It might make sense to re-evaluate how much drag-space is needed once we are closer to the final design and have more exposed toolbar drag space.

Comment 21

[ovidiu boca[:Ovidiu]]

I verified this on Mac OS X 10.10 with Nightly 57.0a1(2017-08-20) and I still can reproduce the issue reported in the description.
Can you please tell me what I need to verify here, based on the fact that this bug is marked as resolved? Thanks

Comment 22

[Dão Gottwald [:dao]]

(In reply to ovidiu boca[:Ovidiu] from comment #21)
> I verified this on Mac OS X 10.10 with Nightly 57.0a1(2017-08-20) and I
> still can reproduce the issue reported in the description.
> Can you please tell me what I need to verify here, based on the fact that
> this bug is marked as resolved? Thanks

That maximizing / zooming the window doesn't remove the drag space.

Comment 23

[ovidiu boca[:Ovidiu]]

I verified this issue on Mac OS X 10.12 with FF Nightly 57.0a1(2017-08-29) and I can confirm the fix. During the verification, I found another bug 1395130. I will mark this as verified fixed.