1642800 - Minimize button is larger when the camera icon is not displayed

Status: VERIFIED FIXED

(Firefox :: Site Permissions, defect, P2)

Description

[Mike Conley (:mconley) (:⚙️)]

Attachment: image.png

Note

Minimize button is larger when the camera icon is not displayed.

Affected versions

nightly v78.0a1
beta b77.0b8

Affected platforms

Windows 10
Windows 7

Steps to reproduce:
Precond:
privacy.webrtc.allowSilencingNotifications - true
privacy.webrtc.legacyGlobalIndicator - false

Engage in a video conference.
Allow the microphone and camera sharing.
Click on the camera icon from the app to set it off.

Expected result

The area with the minimize button should be by design.

Actual result

The area with the minimize button is larger than in the design. Please see the attached screenshot.

Regression range
It is a feature implementation regression.

Additional notes

This issue is found to reproduce in Hangouts and Zoom apps on Windows 10 and 7.
This bug description will suffer changes in the next few days until feature testing is completed.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

This was apparently fixed by bug 1639997, but might need to get reopened after bug 1641546 lands.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

The problem here appears to be that on Windows, for non-popup windows, a minimum width constraint is set on any window: https://searchfox.org/mozilla-central/rev/598e50d2c3cd81cd616654f16af811adceb08f9f/widget/windows/nsWindow.cpp#1801-1802

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Hey mhowell, I wonder if you could help guide me on the best way forward here.

It seems that for non-popup windows (which the WebRTC indicator is soon to become again, because we need it to be minimizable to the task bar and moveable), we clamp the minimum window with to ::GetSystemMetrics(SM_CXMINTRACK) (which amounts to 136px on my Windows 10 machine). It looks like this SM_CXMINTRACK value is supposed to be something that the client code can influence by handling the WM_GETMINMAXINFO message - but that message only seems to be dispatched when the window is moved.

I'm also not 100% sure how to special-case things here for this kind of window. What I really want, ultimately, is to set a min-width on the root element in the WebRTC indicator, and have the Windows widget respect that without clamping. How do I signal the Windows widget backend that I want this, without adding yet another chromeFlag?

Comment 4

[Molly Howell (she/her) [:mhowell]]

My guess at what's happening here is that we've broken a hidden assumption there that any non-popup window must be user-resizable. My basis for that is that the documented meaning of SM_CXMINTRACK says "The user cannot drag the window frame to a size smaller than these dimensions." I think it follows from there that a window which has no frame and which the user cannot resize should not be subject to this constraint, which means we are currently improperly applying it to most if not all dialog windows. Of course this has not been a problem before, because no other window is trying to be as narrow as this one.

So, what I'd like to try is to add one of two things on to the non-popup check: either also check that the window is not a dialog, or, if that would be too broad, check for some specific indicator that the window is user-resizable. For the second option my first thought is to check if the style WS_SIZEBOX is set on the window. It would be better I think (as in, less likely to break something) if the widget object had a way to indicate this property itself, but I haven't found anything like that yet; we might end up having to add the kinds of things that we don't want to add.

I confirmed that adding either the dialog window type or the WS_SIZEBOX check causes this window to get the correct size, but I haven't tried to find or analyze any regressions that may create (and I don't know the widget code well enough to be equipped to think of any).

(In reply to Mike Conley (:mconley) (:⚙️) (Extremely busy) from comment #3)

It looks like this SM_CXMINTRACK value is supposed to be something that the client code can influence by handling the WM_GETMINMAXINFO message - but that message only seems to be dispatched when the window is moved.

If we were getting that message (which I confirmed we are not), I think what it does is override what the windowing system uses as its own limits for a particular window; I wouldn't expect it to change the return value of GetSystemMetrics. Since the limitation we're running up against is one we're imposing on ourselves, and not something that we're telling the windowing system we want it to do, I don't think this would affect anything we're interested in here.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1642800 - Don't enforce minimum window dimensions on non-popup windows if they're not resizable on Windows. r?mhowell

The enforcement is only important when users are able to resize the windows. Otherwise,
we let Gecko set the window dimensions to whatever dimensions they'd like.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7b9cdac2878a
Don't enforce minimum window dimensions on non-popup windows if they're not resizable on Windows. r=mhowell

Comment 7

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/7b9cdac2878a

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 9154609 [details]
Bug 1642800 - Don't enforce minimum window dimensions on non-popup windows if they're not resizable on Windows. r?mhowell

Beta/Release Uplift Approval Request

• User impact if declined: An experiment to use the new WebRTC indicator will run with an indicator that can look somewhat broken.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: Bug 1641546
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a small, well-contained change that changes the rules for minimum window sizes on Windows for a very particular subset of windows (non user-resizable, non popups).
• String changes made/needed: None

Comment 9

[Julien Cristau [:jcristau]]

Comment on attachment 9154609 [details]
Bug 1642800 - Don't enforce minimum window dimensions on non-popup windows if they're not resizable on Windows. r?mhowell

approved for 78.0b6

Comment 10

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/32984c0a0f77

Comment 11

[Daniel Bodea [:danibodea]]

I can confirm that this issue is fixed in Beta v78.0b8 and it does not occur anymore with the newly implemented design in Nightly v79.0a1 on Windows 10 and Windows 7.