User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150525141253 Steps to reproduce: a) Doubleclick the border under toolbar (that border is #navigator-toolbox::after pseudoelement) b) Right-click that border. Actual results: a) Window changed its size: normal/maximized b) Native Windows context menu appears Note: this also works with "borders" on arrows "Left"/"Right" in the tabs toolbar Watch video of my doubleclicks if STR are unclear: https://dl.dropboxusercontent.com/s/0gazzm7elewqe8w/%3D%3Dafter%20pseudoelements%20in%20UI%20are%20act%20like%20a%20part%20of%20application%20window.webm?dl=0

This can only be reproduced with hidden title bar

I think both of these are fixed by bug 1219215.

Bug 1219215 achieved parity between Titlebar shown/hidden, but now I see other bugs (see below) Is it a good idea to leave this (or bug ) 1148886 open for tracking the issues with :after/:before? STR_1: 1. Right-click the :after border under toolbar AR: Nothing ER: Context menu of navigation toolbox should appear STR_2: 1. Click :before border of the right scrollbutton in tabs toolbar AR: Nothing ER: The list of tabs should be scrolled to the right

(In reply to arni2033 from comment #4) > Bug 1219215 achieved parity between Titlebar shown/hidden, but now I see > other bugs (see below) > Is it a good idea to leave this (or bug ) 1148886 open for tracking the > issues with :after/:before? > > STR_1: > 1. Right-click the :after border under toolbar > AR: Nothing > ER: Context menu of navigation toolbox should appear > > > STR_2: > 1. Click :before border of the right scrollbutton in tabs toolbar > AR: Nothing > ER: The list of tabs should be scrolled to the right I believe it would make more sense to file two separate bugs for these. (2) will definitely take a very different fix (indeed, I am not sure it can be fixed at all... IIRC the ::before thing is the shadow, not the border? Am I misremembering? Either way, it's a known issue with XUL toolbarbuttons that clicking on the borders might not work, which generally doesn't apply to the navbar buttons on Windows because the borders are on the xul:image inside the button instead of on the button... not sure offhand about the other toolbars). (1) is now restricted to the context menu, and I'm not sure off-hand how easy it is to fix it. The toolbox doesn't have a context menu as a whole, so "navigation toolbox context menu" doesn't make sense to me. The toolbars do, but the bottom border is drawn as part of the toolbox, not the toolbars, and so it isn't really easy to get the 'right' behaviour there (which presumably would involve showing the context menu of whatever toolbar it borders, so the navbar's toolbar if no other toolbars are below it, but potentially the bookmarks toolbar or even the ones for custom toolbars...). IMHO all of those sound quite tricky, and should just be their own bugs with no confusion about how it relates to the titlebar or window dragging.

(In reply to :Gijs Kruitbosch from comment #5) > (1) The toolbox doesn't have a context menu as a whole, > so "navigation toolbox context menu" doesn't make sense to me. Now I see it... I meant #toolbar-context-menu which contains menuitems: "Move to Menu", "Remove from Toolbar", "Menu Bar", "Bookmarks Toolbar", "Customize..." I can open that context menu in any toolbar, and it really feels like it's default context menu, even though toolbox itself has no connection to that menu. I figured out that (1) can be fixed by simply adding [context="toolbar-context-menu"] to #navigator-toolbox. That's clearly safe, because it only covers areas that had no context menu before. However, I filed (slightly more severe) bug 1250663 to see the decision on that one first. What for (2), I was wrong about "before" - there's no :before and no border! Filed bug 1250664.