923937 - Toolbar acts like regular Windows titlebar when a lightweight theme is installed and the titlebar is not enabled

Status: NEW

(Firefox :: Theme, defect)

Description

[oberscht]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

I installed a theme from the official Mozilla website. This issue seems to appear with themes in general though, and is not theme specific.


Actual results:

Double-clicking the (Navigation or Bookmark) Toolbar maximizes or minimizes Firefox, click-dragging it drags the Firefox window around; all in all it acts like a regular Windows titlebar. This is really annoying when you misclick something on it, forcing you to re-maximize the whole window.


Expected results:

Nothing should happen. The toolbars don't act like this without a theme installed, so installing a theme shouldn't change that.

Comment 1

[KLB]

I can not replicate this on my custom theme.  With what theme(s) are you seeing this issue?

Comment 2

[oberscht]

I am using Dark Fox, but it really appeared with all themes I tried.
Because of what you said, I did some testing with fresh copies of firefox as well as virtual machines, and it appears that you need Aero turned on for this bug to appear.
I have made some GIFs showcasing it, I'll try to attach them.

Comment 3

[oberscht]

Attachment: Shown is the reported bug, which lets you move the whole window by dragging the navigation toolbar.

Comment 4

[oberscht]

Attachment: Same scene, without a theme. Despite clicking around, the window does not move.

Comment 5

[oberscht]

Attachment: Same scene, without Aero. Again, the window does not move.

Comment 6

[KLB]

YAY! I finally replicated the problem.

The problem is with lightweight themes (formally known as "Personas"). Regular complete themes do not exhibit this problem.

On a side note, it is really difficult knowing what people are talking about when two completely different things are both called "themes". Dumbest naming decision ever... well maybe not quite but still confusing.

Comment 7

[:Gijs (he/him)]

Philipp / Felipe, should we revisit this? It feels to me like it doesn't really make sense to most people.

Comment 8

[:Felipe Gomes (needinfo for replies!)]

Sure, this is looking more confusing than helpful to most people by now

Comment 9

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Actually, the behavior should always be as the reporter experienced with an LWT installed. We already do that on Mac and it makes this otherwise dead surface more useful.

Comment 10

[:Gijs (he/him)]

(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #9)
> Actually, the behavior should always be as the reporter experienced with an
> LWT installed. We already do that on Mac and it makes this otherwise dead
> surface more useful.

I think a lot of Windows users would find that behaviour surprising, and it dramatically increases the possibility of misclicks doing something the user doesn't want (like moving the window, or changing its sizemode). It's also really unintuitive that e.g. clicking the space just above the location bar should do something like that (ie change size mode / move the window). It made some sense for glassed areas because they visually looked like the rest of the titlebar - but that is no longer the case on win8+ (and wasn't the case on win xp).

I'd further argue that the consequences are much more severe on Windows than on mac, which has no real concept of maximized/restored windows anyway, nor of aero snapping and so on.

How convinced are you that making this space "more useful" is exclusively a benefit for those users, and/or that potentially surprising behaviour is a better use than keeping the surface "dead" as it is?

Comment 11

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Hm, as with so many things in Windows, there really is no standard. Some applications are only movable via the title bar, others provide more room (like office).
Either way, if we are not deciding to make a larger area dragable, I suggest we wontfix this bug, since the inconsistency only applies to a small segment of users and even within that segment is mostly invisible.