Bug 730219 (chromemargin_changed)

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

NEW
Unassigned

Status

()

Firefox
Extension Compatibility
6 years ago
2 years ago

People

(Reporter: Javier "Darth", Unassigned)

Tracking

(Depends on: 1 bug, {addon-compat, APIchange, regression})

Trunk
Firefox 12
x86_64
Windows 7
addon-compat, APIchange, regression
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
Created attachment 600327 [details]
'micro'-addon for testing 'chromemargin' behavior

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)
(Reporter)

Comment 1

6 years ago
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

Comment 2

6 years ago
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.

Updated

6 years ago
Blocks: 618353
(Reporter)

Comment 3

6 years ago
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).
(Reporter)

Comment 4

6 years ago
... I find this specially useful in small screens (like in netbooks).

Comment 5

6 years ago
Is this primarily for desktops that do not have composition enabled? (glass desktops?)

Comment 6

6 years ago
(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.
(Reporter)

Comment 7

6 years ago
Created attachment 600345 [details]
Example of chromemargin use by "Hide Caption Titlebar Plus" addon (v2)



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
(Reporter)

Comment 8

6 years ago
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.

Comment 9

6 years ago
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.

Comment 11

6 years ago
(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.
(Reporter)

Comment 12

6 years ago
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")

Comment 13

6 years ago
(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?

Comment 14

6 years ago
(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.

Comment 15

6 years ago
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

Comment 16

6 years ago
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?)
(Reporter)

Comment 17

6 years ago
(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 :)
(Reporter)

Comment 18

6 years ago
(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!

Comment 19

6 years ago
(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.

Comment 20

6 years ago
(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.
(Reporter)

Comment 22

6 years ago
(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.

Comment 23

6 years ago
(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?
(Reporter)

Comment 24

6 years ago
(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])
(Reporter)

Comment 25

6 years ago
... 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: + → ---
(Reporter)

Comment 28

6 years ago
(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.
(Reporter)

Comment 29

6 years ago
(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
(Reporter)

Comment 30

6 years ago
... 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.

Comment 31

5 years ago
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.

Comment 32

5 years ago
(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.
(Reporter)

Comment 33

5 years ago
(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).

Comment 34

5 years ago
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".

Comment 35

5 years ago
(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.

Updated

5 years ago
Depends on: 741404

Comment 36

5 years ago
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?

Comment 37

5 years ago
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.

Comment 38

5 years ago
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.

Comment 39

5 years ago
Created attachment 620230 [details]
Firefox 11 beauty, Firefox 12 ugliness

Comment 40

5 years ago
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: + → ---

Comment 42

5 years ago
(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.

Comment 43

5 years ago
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

Comment 44

4 years ago
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.

Comment 45

4 years ago
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.

Comment 46

4 years ago
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?

Comment 47

4 years ago
Actually, that seems to be the case in Firefox 27 as well... I wonder when exactly this was fixed...

Comment 48

4 years ago
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...

Updated

4 years ago
Depends on: 975822
(Reporter)

Comment 49

3 years ago
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).

Updated

3 years ago
Assignee: jmathies → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

3 years ago
Flags: firefox-backlog+

Updated

3 years ago
Flags: firefox-backlog+ → firefox-backlog-
You need to log in before you can comment on or make changes to this bug.