1195067 - The window itself can be dragged by dragging the bookmarks bar (or the menu button separator) when a lightweight theme is in use

Status: NEW

(Firefox :: Theme, defect)

Description

[arni2033]

Attachment: The window itself can be dragged if you press left mouse button on bookmarks bar.webm

STR:
1.A) Place mouse over bookmarks bar
1.B) Place mouse over separator between hamburger buggon and other buttons (in navigation bar)
2.   Press left mouse button (don't release it)
3.   Move mouse

Result:       [watch video] The window changed it's size and position
Expectations: The window should stay still

Note: On the video I press Esc so that window got back to the initial state.
      ::after pseudoelements act that way on every built-in theme, see bug 1171467

Comment 1

[arni2033]

(Win7, Nightly 43.0a1 (2015-08-15))
Note that it happens on NON-HiDPI as well

Comment 2

[arni2033]

(This can only be reproduced with hidden title)

Comment 3

[:Gijs (he/him)]

I can reproduce this with other lightweight themes as well (the devedition theme is internally implemented using a lightweight theme). This isn't an issue on OS X because there it's expected that this is how window dragging works, but I can reproduce the difference on Windows. Felipe, can you comment as to how much of this is by design on Windows, and/or if you have any idea why this is different with a lightweight theme applied vs. without it?

Comment 4

[:Felipe Gomes (needinfo for replies!)]

Attachment: Comparison default and LWTheme - win7

Yeah, this is entirely by design from the Win7 theme. It's due to what looks visually as part of the titlebar. When there is no theme applied, the glass area is just above the urlbar. With a lwtheme, the theme background extends itself all the way through the bookmarks bar, so everything that looks as part of titlebar gets to drag the window.

Comment 5

[:Gijs (he/him)]

(In reply to :Felipe Gomes from comment #4)
> Created attachment 8649904 [details]
> Comparison default and LWTheme - win7
> 
> Yeah, this is entirely by design from the Win7 theme. It's due to what looks
> visually as part of the titlebar. When there is no theme applied, the glass
> area is just above the urlbar. With a lwtheme, the theme background extends
> itself all the way through the bookmarks bar, so everything that looks as
> part of titlebar gets to drag the window.

Should we disable this just for the devedition theme?

Comment 6

[Brian Grinstead [:bgrins]]

(In reply to :Gijs Kruitbosch from comment #5)
> (In reply to :Felipe Gomes from comment #4)
> > Created attachment 8649904 [details]
> > Comparison default and LWTheme - win7
> > 
> > Yeah, this is entirely by design from the Win7 theme. It's due to what looks
> > visually as part of the titlebar. When there is no theme applied, the glass
> > area is just above the urlbar. With a lwtheme, the theme background extends
> > itself all the way through the bookmarks bar, so everything that looks as
> > part of titlebar gets to drag the window.
> 
> Should we disable this just for the devedition theme?

That seems OK to me

Comment 7

[:Felipe Gomes (needinfo for replies!)]

No strong opinion for or against it. I guess it doesn't look like a big problem to spend time on it.. but perhaps it could be a good first bug? To fix it we need to change this selector:
http://mxr.mozilla.org/mozilla-central/source/browser/themes/windows/browser-aero.css?rev=c6a3767c30fc#380
to not apply to DevEdition

Comment 8

[:Gijs (he/him)]

(In reply to :Felipe Gomes (away Dec 19 - Jan 2, use needinfo!) from comment #4)
> Created attachment 8649904 [details]
> Comparison default and LWTheme - win7
> 
> Yeah, this is entirely by design from the Win7 theme. It's due to what looks
> visually as part of the titlebar. When there is no theme applied, the glass
> area is just above the urlbar. With a lwtheme, the theme background extends
> itself all the way through the bookmarks bar, so everything that looks as
> part of titlebar gets to drag the window.

This seems to be unexpected for at least some users, cf. bug 1236191 comment #0. Was this implemented after or before user feedback? It also strikes me as odd if we're doing this just on win7/vista, but not on windows 8 - with a lwt, there's almost no difference between the two OSes where overall visual appearance of the toolbox is concerned.

Comment 9

[:Felipe Gomes (needinfo for replies!)]

I don't think there was ever a grand design or spec on how this should work. At the time it was a "sounds about right" and a quick consultation with either Faaborg or Shorlander. The fact that it doesn't work in Win8 is not by design, just a theme bug.

Personally I find most of the draggable areas posted in the screenshot in bug 1236191 comment #0 to be a good thing, except perhaps the violet areas next to the tab scrollers < >.
(The thin wide stretch posted in the second screenshot there is definitely a bug though)

I'm fine with changing any of that, just keeping in mind that there are already few points in where the browser is draggable, and while it might be undesirable for some users, some others might be relying on those to move the window.

Comment 10

[arni2033]

(In reply to :Felipe Gomes (needinfo me!) from comment #9)
> most of the draggable areas posted in the screenshot in bug 1236191 comment #0 to be a good thing
> some others might be relying on those to move the window
1) On Dev_Edition_Theme the indents between urlbar/searchbar and tabs toolbar are 3px in height
2) The 1px separator between nav.toolbox and content is also red (I worry it's not noticeable)
 In my understanding, it's better not to expect/force user to use/rely on a target which is 1-3px in width/height, unless it's located at the edge of the screen (e.g. fullscreen separator). So I really hope that your final decision will imply removal of all such "accidental" targets (thin red areas)

 Actually, the violet area below window controls is one of those "accidental" targets.
 Violet areas are presented on all themes (default theme, lwthemes, dev_edition_theme), therefore I don't expect any of them to ever be fixed.