Closed Bug 730219 (chromemargin_changed) Opened 12 years ago Closed 6 years ago

'chromemargin' attribute changed behavior, can't disable window caption's (min,max,close) buttons anymore. Breaks Addon.

Categories

(Firefox :: Extension Compatibility, defect)

Product:
Firefox
Component:
Extension Compatibility
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Firefox 12

People

(Reporter: redlibrepy, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: addon-compat, APIchange, regression)

Attachments

(5 files, 1 obsolete file)

'micro'-addon for testing 'chromemargin' behavior
2.67 KB, application/octet-stream
Details
Example of chromemargin use by "Hide Caption Titlebar Plus" addon (v2)
36.64 KB, image/png
Details
Illustrate "Hide Caption Titlebar plus" breakage in Firefox 12,13,14
166.20 KB, image/png
Details
example of layout made possible by this plugin but broken on FF12.
89.83 KB, image/png
Details
Firefox 11 beauty, Firefox 12 ugliness
232.12 KB, image/jpeg
Details 
Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120223 Firefox/13.0a1
Tested in Aero-Glass.

Reproducible: Always.  (starting from Firefox Aurora (12a) up to last Nightly)


The main issue is that it can't be used anymore to *deactivate window caption's (min,max,close) buttons*.  In Firefox 11 or below, if you use a 'chromemargin' value of "1,0,0,0" those buttons are deactivated (despite them been still visible).  (The value "1,-1,-1,-1" also works for maximized mode. The key for this is using top-margin > 0)

This is breaking my addon "Hide Caption Titlebar Plus" [http://tiny.cc/hidec] (and likely any similar one) that uses It's own set of caption buttons (very similar to Firefox's FULLSCREEN mode).  (I'm getting a steady flow of 'addon broken' reports by now)

So please, if you can restore that behavior or provide another solution/value combination to do that, it'd be very appreciated.  The absolute higher priority is for Maximized mode.  

Attached is a 'micro'-addon for testing 'chromemargin' behavior and see the difference between Fx versions.

Thanks in advance!


Steps to Reproduce:
1- Put a 'chromemargin' value of "1,0,0,0" ("1,-1,-1,-1" for Maximized mode) (You can use the attached 'micro'-addon, better do it in a new profile)

Actual Results:  
- The entire window system (standard) caption is visible, caption buttons are clickable.

Expected Results:  
- Caption (min,max,close) buttons are deactivated (visible but not clickable), system caption hidden. (like Fx 11 and below does)
Related info: 
Starting from Fx 12a there is a new default value for 'chromemargin' attr. (0,2,2,2) that renders thinner window borders.  Also rules/behavior changes from what is described in https://developer.mozilla.org/en/XUL/Attribute/chromemargin
Keywords: addon-compat, APIchange
Why would you want to deactivate the users caption buttons while still keeping them visible? I guess I don't understand the point of your extension.
Blocks: 618353
In addition to deactivating, I'm hiding them (with xul) and replacing with smaller XUL buttons. 

The main feature of my addon "Hide Caption Titlebar Plus" is to maximizing content space (Ie. by doing like attached screenshot, has other configurable options).
... I find this specially useful in small screens (like in netbooks).
Is this primarily for desktops that do not have composition enabled? (glass desktops?)
(In reply to Jim Mathies [:jimm] from comment #5)
> Is this primarily for desktops that do not have composition enabled? (glass
> desktops?)

I went ahead and installed your extension. Let me take a look "under the hood" at what's going on and I'll post back.
Well, most the other way (for Aero glass desktops), but will need support for Aero Basic (netbooks like mine) and if possible Win XP too (I only tested this bug with Glass). I think that addon users that gets uncovered will not like it (and will complain loudly to me 1st :)
Attachment #600338 - Attachment is obsolete: true
Btw, If you can come with a way to deactivate (& hide) those buttons without having to set chromemargin to (1,x,x,x), that would be a lot better.
Tracking for FF12 and 13 due to the possibility of add-on compatibility issues. If not many add-ons are affected or the effect is fairly minimal, we'll consider untracking.
Assignee: nobody → jmathies
tracking-firefox12: ? → +
tracking-firefox13: ? → +
I see about a dozen add-ons on AMO that use 'chromemargin', but I don't know if they are all affected by this change. We'll add a compatibility validation warning so developers are aware of it.
(In reply to Jorge Villalobos [:jorgev] from comment #10)
> I see about a dozen add-ons on AMO that use 'chromemargin', but I don't know
> if they are all affected by this change. We'll add a compatibility
> validation warning so developers are aware of it.

If the values set of either 0, or -1 for the params, they will be ok. If they use a positive number we've changed the behavior they are relying on.
I only need a way to deactivate the caption buttons like chromemargin="1,x,x,x" did, at least maybe a last-resort workaround like ie. chromemargin="-5,x,x,x" or whatever other flag/attr. (I've watched Jim's patch in Bug 618353)
I'm willing to accommodate my addon to whatever solution that may come, by all means. :)  

(I'm holding already a bugfix and a mayor addon release.  A main feature is the choice to use customizable caption buttons instead the system ones, like ie. attachment 600345 [details])

Sorry to be a pest.
Thanks a lot!

(As an absolute less priority and if can be done, I'd like to deactivate those buttons and have the window top-border like in chromemargin="0,x,x,x")
(In reply to Javier "Darth Madara" from comment #12)
> I only need a way to deactivate the caption buttons like
> chromemargin="1,x,x,x" did, at least maybe a last-resort workaround like ie.
> chromemargin="-5,x,x,x" or whatever other flag/attr. (I've watched Jim's
> patch in Bug 618353)
> I'm willing to accommodate my addon to whatever solution that may come, by
> all means. :)  
> 
> (I'm holding already a bugfix and a mayor addon release.  A main feature is
> the choice to use customizable caption buttons instead the system ones, like
> ie. attachment 600345 [details])
> 
> Sorry to be a pest.
> Thanks a lot!
> 
> (As an absolute less priority and if can be done, I'd like to deactivate
> those buttons and have the window top-border like in chromemargin="0,x,x,x")

By deactivate, do you mean completely hide, or simply make them not work?
(In reply to Javier "Darth Madara" from comment #3)
> Created attachment 600338 [details]
> Example of chromemargin use by "Hide Caption Titlebar Plus" addon
> 
> In addition to deactivating, I'm hiding them (with xul) and replacing with
> smaller XUL buttons. 
> 
> The main feature of my addon "Hide Caption Titlebar Plus" is to maximizing
> content space (Ie. by doing like attached screenshot, has other configurable
> options).

nm, needed to read back through the bug.
Have you tried removing the titlebar-buttonbox or titlebar-buttonbox-container from xul layout?

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.xul#434
Note for release drivers - this should not track 12. We changed the way an attribute works, but the gain far out weighs the negative side effects for the few addons that might be using this. I'm pretty sure we can come up with alternative solutions.

It would be nice to know from the AMO folks how many addons actually use the value that changed. (per comment 10 and comment 11). (Jorge?)
(In reply to Jim Mathies [:jimm] from comment #15)
> Have you tried removing the titlebar-buttonbox or
> titlebar-buttonbox-container from xul layout?
> http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.
> xul#434

I've tried exactly that with today's Nightly and no results (separate tries to remove both things from browser.xul). I removed even the whole #titlebar (live, using Dom inspector) and the caption buttons remains clickable (with their glow-on-hover also).
Win7-64 with Aero Glass.


(In reply to Jim Mathies [:jimm] from comment #13)
> By deactivate, do you mean completely hide, or simply make them not work?
(In reply to Jim Mathies [:jimm] from comment #14)
> nm, needed to read back through the bug.

No prob. I need simply make them not work, just to be clear :)
(In reply to Jim Mathies [:jimm] from comment #16)
> Note for release drivers - this should not track 12. We changed the way an
> attribute works, but the gain far out weighs the negative side effects for
> the few addons that might be using this. I'm pretty sure we can come up with
> alternative solutions.

Sorry If I'm wrong, but would that mean that Fx12 may be released with this bug? I'm pretty sure that this can be solved without going back with any of the good fixes in Bug 618353 patch (Ie: If there isn't another easier way, can't that part be touched to include a condition for chromemargin="-5,x,x,x" or something like that?, as an absolutely undocumented feature if You want)
Thanks!
(In reply to Javier "Darth Madara" from comment #17)
> (In reply to Jim Mathies [:jimm] from comment #15)
> > Have you tried removing the titlebar-buttonbox or
> > titlebar-buttonbox-container from xul layout?
> > http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.
> > xul#434
> 
> I've tried exactly that with today's Nightly and no results (separate tries
> to remove both things from browser.xul). I removed even the whole #titlebar
> (live, using Dom inspector) and the caption buttons remains clickable (with
> their glow-on-hover also).
> Win7-64 with Aero Glass.

We don't draw those buttons, windows does if there is glass present. So removing the titlebar or replacing the titlebar button box with your own content and rendering on top of that should replace the buttons. If the glass remains though windows will paint them. The only way to remove these w/glass would require new window. apis or similar to better control window decorations.

To get a better feel you can switch to aero basic mode and clip the titlebar button box out, in that case the buttons should go away since we paint those internally.
(In reply to Javier "Darth Madara" from comment #18)
> (In reply to Jim Mathies [:jimm] from comment #16)
> > Note for release drivers - this should not track 12. We changed the way an
> > attribute works, but the gain far out weighs the negative side effects for
> > the few addons that might be using this. I'm pretty sure we can come up with
> > alternative solutions.
> 
> Sorry If I'm wrong, but would that mean that Fx12 may be released with this
> bug? I'm pretty sure that this can be solved without going back with any of
> the good fixes in Bug 618353 patch (Ie: If there isn't another easier way,
> can't that part be touched to include a condition for
> chromemargin="-5,x,x,x" or something like that?, as an absolutely
> undocumented feature if You want)
> Thanks!

It's not a bug really, it's a change to an attribute we support. The "disable feature" you were relying on wasn't officially supported, it was really just a strange byproduct of how windows implements the command buttons on windows with custom client margins. I don't even know what was originally causing it, technically, the feature was a bug.
(In reply to Jim Mathies [:jimm] from comment #16)
> It would be nice to know from the AMO folks how many addons actually use the
> value that changed. (per comment 10 and comment 11). (Jorge?)

Only 3 add-ons appear to match the criteria in comment 11.
(In reply to Jim Mathies [:jimm] from comment #20)
> (In reply to Javier "Darth Madara" from comment #18)
> > Sorry If I'm wrong, but would that mean that Fx12 may be released with this
> > bug? I'm pretty sure that this can be solved without going back with any of
> > the good fixes in Bug 618353 patch (Ie: If there isn't another easier way,
> > can't that part be touched to include a condition for
> > chromemargin="-5,x,x,x" or something like that?, as an absolutely
> > undocumented feature if You want)
> > Thanks!
> 
> It's not a bug really, it's a change to an attribute we support. The
> "disable feature" you were relying on wasn't officially supported, it was
> really just a strange byproduct of how windows implements the command
> buttons on windows with custom client margins. I don't even know what was
> originally causing it, technically, the feature was a bug.

Well, maybe It's undocumented -and not officially supported-, but the way windows behave, say, deactivating those buttons when using custom client margins seems to be a logical step in the right direction to me. I'd expect -at least- that when using such margins, and If I'm not mistaken, that was the exact thing I can request since Fx4 through  chromemargin > 0 values. 
That said, I understand that an attribute like this, can be changed to make improvements/fixes, that's why I'm not requesting all that chromemargin logic to return, but only a way to continue using XUL customizable buttons there.
(In reply to Javier "Darth Madara" from comment #22)
> (In reply to Jim Mathies [:jimm] from comment #20)
> > (In reply to Javier "Darth Madara" from comment #18)
> > > Sorry If I'm wrong, but would that mean that Fx12 may be released with this
> > > bug? I'm pretty sure that this can be solved without going back with any of
> > > the good fixes in Bug 618353 patch (Ie: If there isn't another easier way,
> > > can't that part be touched to include a condition for
> > > chromemargin="-5,x,x,x" or something like that?, as an absolutely
> > > undocumented feature if You want)
> > > Thanks!
> > 
> > It's not a bug really, it's a change to an attribute we support. The
> > "disable feature" you were relying on wasn't officially supported, it was
> > really just a strange byproduct of how windows implements the command
> > buttons on windows with custom client margins. I don't even know what was
> > originally causing it, technically, the feature was a bug.
> 
> Well, maybe It's undocumented -and not officially supported-, but the way
> windows behave, say, deactivating those buttons when using custom client
> margins seems to be a logical step in the right direction to me. I'd expect
> -at least- that when using such margins, and If I'm not mistaken, that was
> the exact thing I can request since Fx4 through  chromemargin > 0 values. 
> That said, I understand that an attribute like this, can be changed to make
> improvements/fixes, that's why I'm not requesting all that chromemargin
> logic to return, but only a way to continue using XUL customizable buttons
> there.

Are you maintaining glass areas in the titlebar area with your addin enabled?
(In reply to Jim Mathies [:jimm] from comment #23)
> (In reply to Javier "Darth Madara" from comment #22)
> > ... but only a way to continue using XUL customizable buttons there.
> 
> Are you maintaining glass areas in the titlebar area with your addin enabled?

Yes, I'm hiding only the buttons area with a <hbox>. (that box can be seen behind my own butons in  attachment 600327 [details])
... sorry, I meant the screenshot at attachment 600345 [details]
(In reply to Jorge Villalobos [:jorgev] from comment #21)
> (In reply to Jim Mathies [:jimm] from comment #16)
> > It would be nice to know from the AMO folks how many addons actually use the
> > value that changed. (per comment 10 and comment 11). (Jorge?)
> 
> Only 3 add-ons appear to match the criteria in comment 11.

Can we get the list of add-ons to see if QA can reproduce this issue? If not, we can untrack for release. Thanks!
This breaks some add-ons but it isn't major. It affects very few add-ons and they were taking advantage of unintended behavior of a feature.

Untracking.
tracking-firefox12: + → ---
(In reply to Javier "Darth Madara" from comment #24)
> (In reply to Jim Mathies [:jimm] from comment #23)
> > (In reply to Javier "Darth Madara" from comment #22)
> > > ... but only a way to continue using XUL customizable buttons there.
> > 
> > Are you maintaining glass areas in the titlebar area with your addin enabled?
> 
> Yes, I'm hiding only the buttons area with a <hbox>. (that box can be seen
> behind my own butons in ... the screenshot at attachment 600345 [details])

But of course, the capacity to use custom XUL buttons is a very high priority, so if losing the glass effect can be a way/workaround for that to return, lets go with it for the time being.
(In reply to Jorge Villalobos [:jorgev] from comment #27)
> This breaks some add-ons but it isn't major. It affects very few add-ons and
> they were taking advantage of unintended behavior of a feature.
> 
> Untracking.

I should say that in the case of the 'Hide Caption Titlebar Plus' addon, since Fx4 I had used chromemargin to set custom client margins as documented (and now those rules had changed also). The effect of deactivating the system buttons is undocumented but I'd not call it unintended for the reasoning in comment #22.

The main issue for me remains as what path to follow from now on with this. The possibility to lose a main feature like the use of customizable XUL buttons would render the addon highly unusable and there is also the great problem that would be to support/explain such a lose to the 17000 average addon users.

AFAIK based on Bug 618353 patch, I'm evaluating that it is not difficult to incorporate an extra condition ('if') for this (Ie. chromemargin="-5,.. thing discussed before), because I saw it changed some conditions in specific cases where there isn't allowed anymore chromemargin values > 0.  Because of all this, the effects that this lose will have and that I'm not seeing another way to do this, I see this as a regression case.

Thank you
Keywords: regression
... just in case, I think that the lose will impact the addon and it's future roadmap severely (including an incoming major release) even if _only_ Fx12 is affected.
To illustrate why it is desirable to let an addon like Hide Caption Titlebar plus continue to function also in versions beyond Firefox 11 I’ve attached a picture showing my current browser customization.
For me this breakage is a strong reason to stay on version 11 of Firefox even as newer versions become available.
(In reply to Stellan Klebom from comment #31)
> Created attachment 605986 [details]
> Illustrate "Hide Caption Titlebar plus" breakage in Firefox 12,13,14
> 
> To illustrate why it is desirable to let an addon like Hide Caption Titlebar
> plus continue to function also in versions beyond Firefox 11 I’ve attached a
> picture showing my current browser customization.
> For me this breakage is a strong reason to stay on version 11 of Firefox
> even as newer versions become available.

As far as work arounds go, I haven't found much. You can still draw on top of these buttons, but the glow and interaction remains. Independent of creating a new api to control the visibility of these buttons, which we can add but it's not a trivial change, I think your best bet is to move your extra button to the side of the regular caption buttons, and leave the existing caption buttons in place.
(In reply to Jim Mathies [:jimm] from comment #32)
> As far as work arounds go, I haven't found much. You can still draw on top
> of these buttons, but the glow and interaction remains. Independent of
> creating a new api to control the visibility of these buttons, which we can
> add but it's not a trivial change, I think your best bet is to move your
> extra button to the side of the regular caption buttons, and leave the
> existing caption buttons in place.

It happens that this is one of main capabilities of Firefox until now, to allow addons to use customizable XUL buttons that can be located on the *screen corner*. This is the most valuable spot to have configurable button/s, due to Fitt's Law (in Wikipedia, see about 'Edges & Corners') (1).  (Alex Faaborg also did some nice research & pictures illustrating the value of edges and corners in the Fx4 times when tabs-on-top was incorporated.)  All that is lost if addons can't deactivate the system buttons anymore.

I of course may be wrong, but I'm still thinking that should be pretty easy to add any sort/kind of flag to revert the precise (or all) changes of Bug 618353 patch (that took away the capability mentioned above), whichever way is easier for you.  This way, the regular Firefox 12+ can stay the same It is now but will allow addons to give back that capability.
This is the only really needed change.  The visibility control you mentioned is a nice-to-have feature, but It is outside the scope of this (regression) bug.
Thank you!


(1) Screen corner use (Fitt's Law): I for example, use a close button there that I configure to close the current tab, an operation I do very frequently. So with this, I can keep reading and follow links that keep opening new tabs, and later I can quickly close those tabs without moving my eye sight even a little bit (I simply quickly 'bump' the mouse to the screen corner & do the click).
Example where you can use the plugin to completely remove the window buttons, maximize the useful chrome area and still keep the tabs under the address bar.
The screenshots are taken from XP.
P.S. The other extension I use to achieve this particular layout is "Movable Firefox Button".
(In reply to alejandro from comment #34)
> Created attachment 611460 [details]
> example of layout made possible by this plugin but broken on FF12.
> 
> Example where you can use the plugin to completely remove the window
> buttons, maximize the useful chrome area and still keep the tabs under the
> address bar.
> The screenshots are taken from XP.
> P.S. The other extension I use to achieve this particular layout is "Movable
> Firefox Button".

Removing the default buttons is still possible on XP and aero basic themes. This bug only applies to aero glass desktops since we rely on Windows to draw the buttons there due to their use of hover glow, which falls outside the contents of the window.
Depends on: 741404
ok. I didn't know that. but as you can see from the screenshot the plugin is broken on FF12. Even for XP. But from what you say I guess the author of the plugin could make it work again at least in XP, right?
oh, I see. I guess the buttons are shown even on XP because the plugin detects it is running on FF12 and decides to not try to hide them.
For those of you who are still on XP and want to hide the window buttons, you can just add the following line to "userChrome.css":

#titlebar-buttonbox-container {display: none !important;}

It wont work as good as the plugin though ("Hide Caption Titlebar Plus"), since they will be always hidden. When using the plugin you had the option to only hide them on maximized windows.
Dear developers, I salute you.

Months passing-by, still zealous arguing of divergent viewpoints, and it is not about budget, politics, or religion. I'm not a pundit, I'm the one who suffers, and my cure lies within a little effort of yours. So, who will bring down the peace with this issue? We need a synergy to advance, let's implement this feature and move on.

Warm regards from Russia,
Alexander.
also removing tracking for 13 based on comment 27
tracking-firefox13: + → ---
(In reply to Alexander Sergeyev from comment #40)
> Dear developers, I salute you.
> 
> Months passing-by, still zealous arguing of divergent viewpoints, and it is
> not about budget, politics, or religion. I'm not a pundit, I'm the one who
> suffers, and my cure lies within a little effort of yours. So, who will
> bring down the peace with this issue? We need a synergy to advance, let's
> implement this feature and move on.
> 
> Warm regards from Russia,
> Alexander.

Bug 741404 currently tracks adding this feature back in the correct way.
I was wondering couldn't you build your app with this:

#titlebar {display: none !important;}
#main-window {-moz-appearance:none !important;}

The first one would just remove the titlebar and you could just rebuild the menu button and the second one would just remove the window moz.

Regards,
Harvey
you can simply add some attribute to tell windows to not draw the three buttons. after all, you do that on one of your popups in the crash report, so you could do that in the main window, thereby allowing you to add your own custom buttons.
plus, this way is better than the chromemargin in the way that you would not need to cover anything.
I mean a toggle on whether to allow windows to draw the caption buttons or not.
one other use for this is if a theme wants to use it's own custom buttons without getting rid of aero. if you have a toggle, then there is no harm done. that is the best solution.
Seems this bug is fixed in version 29(in fullscreen the small buttons show on an aero background) as per the Australis spec specifying custom drawn window buttons... Can someone confirm?
Actually, that seems to be the case in Firefox 27 as well... I wonder when exactly this was fixed...
Actually I was using this user style: http://userstyles.org/styles/41182/firefox-7-about-blank-glass 
Which removed the background of fullscreen mode, which revealed an aero window, with the borders barely visible on the side, and the default aero caption buttons completely gone. Which still brings up the question of Why and how fullscreen has aero without the caption buttons...
Depends on: 975822
Hi Rexy,
Tks a lot, I know already that aero look in fullscreen. But It seems to me that It is like the same as when using window's "hidechrome" attr, like this:
  <window  hidechrome="true" >
But unfortunately, with this attr. Fx behaves very weird when un/maximizing. (btw, if you maximize first and then activates "hidechrome" the 'clean' glass effect seems to look even better that in fullscreen)
So, I concluded a long time ago that this can't be the way to remove the caption-buttons, sorry.

BTW in Firefox for LINUX, this "hidechrome" attr, is indeed *very useful* bc It allows to get rid of the system-titlebar. (I'm using it also in my addon).
Assignee: jmathies → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: firefox-backlog+
Flags: firefox-backlog+ → firefox-backlog-
Mass-closing old Extension Compatibility bugs that relate to legacy add-ons or NPAPI plug-ins. If you think this bug is still valid, please reopen or comment.

Sorry for the bug spam, and happy Friday!
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: