Curve that connects tab to navBar/contentArea should be more curved, gradual, smoother and have more overlap on background tabs

Blocking 2.0? Unless the tentative code freeze of tomorrow actually sticks.

The entire meta bug is blocking 2.0. The only question is which milestone.

Bug 554982 partly spoils the appearance here with tabs on bottom.

I confirm this bug also for at least MacOSX. You should adjust "Platform: x86 Windows 7" to at least "Platform: x86 Windows 7 Mac OSX" or to "Platform: x86 All" in the bug's information.

(In reply to comment #5) > I confirm this bug also for at least MacOSX. > You should adjust "Platform: x86 Windows 7" to at least "Platform: x86 Windows > 7 Mac OSX" or to "Platform: x86 All" in the bug's information. See also https://wiki.mozilla.org/Firefox/Projects/New_Theme/Timeline . That page should also be adjusted with respect to this bug and reflecting the outstanding bugs on Mac platform an Linux platform. For instance only the [Windows] Theme Requirements (in order of priority) incl. screenshots mentions Bug 570279 and Bug 570282, although these two bugs also do apply on Mac OSX and Linux as well concerning "Tabs on Top" (Tabs on Bottom are curved, Tabs on Top are not curved) -- compare 1st screenshot (Tabs on Top) with 2nd screenshot (Tabs on Bottom) of either platform.

Frank, any ETA?

hm? Original summary was much more descriptive and concrete.

Since implementing a proper connecting curve would require negative margins and other voodoo (including SVG), we're going with a more angular appearance that eschews lower concave corners for this release (Firefox 4). Screenshot coming up.

Said screenshot attached, showing tabs' appearance on backgrounds of varying lightness.

pixel push to make tabs-on-bottom look better and reduce UI movement when switching to personas (part of bug 616010).

Comment on attachment 516180 [details] [diff] [review] better patch for cleaner tabs >- #main-window[sizemode="normal"] #TabsToolbar[tabsontop="true"]:not([inFullscreen="true"]):not(:-moz-lwtheme) { >+ #main-window[sizemode="normal"] #TabsToolbar:not([inFullscreen]) { > padding-left: 4px; > padding-right: 4px; > } Why are you removing the tabs-on-top condition? >+.tabbrowser-tab { >+ -moz-margin-end: 1px; > } Margins on tabs cause weirdness with scrolling, last time I checked. This change isn't really necessary, is it? I.e. the gap could remain part of the border.

(In reply to comment #13) > Why are you removing the tabs-on-top condition? It's a bit strange to have the leftmost tab flush with the left border of the content area, which happens in aero. TBH, I don't care about tabs-on-bottom mode, so if that seems okay to you, i'll leave the condition in. > >+.tabbrowser-tab { > >+ -moz-margin-end: 1px; > > } > > Margins on tabs cause weirdness with scrolling, last time I checked. > This change isn't really necessary, is it? I.e. the gap could remain part of > the border. What sort of weirdness? I tried reproducing and didn't find any. With the gap in the border, we end up with an asymmetric border, since we want a one pixel gap, and it's difficult to specify a border-radius that will work the same on each side. I suppose we can approximate it if we need to, since it's already that way as is. |border-radius: 10px 8px 0 0;| etc. If that's really the best approach we've got, I'll update a patch with that later today.

(In reply to comment #14) > It's a bit strange to have the leftmost tab flush with the left border of the > content area, which happens in aero. TBH, I don't care about tabs-on-bottom > mode, so if that seems okay to you, i'll leave the condition in. I think we'd probably want a 1px or 2px padding in that case. The 4px were added because of the radius on the nav bar with tabs on top. > > Margins on tabs cause weirdness with scrolling, last time I checked. > > This change isn't really necessary, is it? I.e. the gap could remain part of > > the border. > > What sort of weirdness? Like, the tab strip not scrolling completely to the end when selecting the last tab.

(In reply to comment #10) > Created attachment 516164 [details] [diff] [review] > patch for cleaner tabs > > Since implementing a proper connecting curve would require negative margins and > other voodoo (including SVG), we're going with a more angular appearance that > eschews lower concave corners for this release (Firefox 4). Screenshot coming > up. So Firefox on Mac was able to use this "voodoo", but on Windows not?

(In reply to comment #16) > So Firefox on Mac was able to use this "voodoo", but on Windows not? Firefox on Mac has the tabs redone in SVG.

(In reply to comment #17) > (In reply to comment #16) > > So Firefox on Mac was able to use this "voodoo", but on Windows not? > > Firefox on Mac has the tabs redone in SVG. I think that's what he was implying. So why can't the same be done for Windows?

I discussed with Stephen, and it turns out that we don't actually want the gap (at least for this release), so the patch is now just some CSS pixel pushing and an image drop.

AIUI, Stephen already knows what this looks like, so it should be good to go.

minor addition to the previous patch that gives app tabs space to breathe. explanation of low risk: no javascript. no c++. css only pushes pixels; no behavior change. single image drop that is a non-animated PNG.

Comment on attachment 516484 [details] screenshot of above patch Looks great!

Comment on attachment 516483 [details] [diff] [review] patch (now gives app tabs space to breathe) Explanation of patch for dolske: >- #main-window[sizemode="normal"] #TabsToolbar[tabsontop="true"]:not([inFullscreen="true"]):not(:-moz-lwtheme) { >+ #main-window[sizemode=normal] #TabsToolbar[tabsontop=true]:not([inFullscreen]) { Makes switching to a persona not cause the tabs toolbar to shift awkwardly. >+ #main-window[sizemode=normal] #TabsToolbar[tabsontop=false]:not([inFullscreen]) { >+ padding-left: 2px; >+ padding-right: 2px; >+ } In tabs-on-bottom mode in areo, make the leftmost tab not awkwardly be flush with the left border of the content area. > .tabbrowser-tab, > .tabs-newtab-button { ... >- background-size: 100% -moz-calc(100% - 2px); >+ background-size: -moz-calc(100% - 2px) -moz-calc(100% - 2px); ... >- -moz-border-image: url(tabbrowser/tab.png) 4 5 3 6 / 4px 5px 3px 6px repeat stretch; >- border-radius: 10px 8px 0 0; >+ -moz-border-image: url(tabbrowser/tab.png) 6 3 4 / 6px 3px 4px repeat stretch; >+ border-radius: 7px 7px 0 0; ... > .tab-throbber, > .tab-icon-image { ... >+ -moz-margin-start: 2px; Make the tabs symmetrical and adjust the background/width/padding/border values for the new tab.png dimensions. > .tab-throbber[pinned], > .tab-icon-image[pinned] { >- -moz-margin-start: 2px; >- -moz-margin-end: 2px; >+ -moz-margin-start: 5px; >+ -moz-margin-end: 5px; > } Give app tabs 1 pixel more padding on each side. (It looks like 3 pixels, but 2 of them are for the new tab.png dimensions.) > .tabs-newtab-button { >- width: 31px; >+ width: 30px; > } Make the new tab button's icon be centered. ... >GIT binary patch ... Update tab.png! Thanks, Stephen!

So ugly!

Comment on attachment 516483 [details] [diff] [review] patch (now gives app tabs space to breathe) Basically fine, although when we checked on XP the first tab looks a little too close to the window border now. Frank's updating for that case. Should be r+ with that fixed.

I think it looks beautiful! Much cleaner and "lighter" feeling. Great work!

Restores tabs toolbar padding for Windows XP non-classic.

Comment on attachment 516500 [details] [diff] [review] patch a=beltzner, let's get this in nightlies Fryn: can you post (gulp) on MozillaZine asking people to hammer on the nightly and point out oddities in various Windows theme modes?

I want to point out that this will likely cause churn where we already have screenshots (SUMO, marketing and promo materials, and MDN?) taken of FF4. This looks pretty different to me at first glance, though admittedly I don't live on Windows.

(In reply to comment #32) > I want to point out that this will likely cause churn where we already have > screenshots (SUMO, marketing and promo materials, and MDN?) taken of FF4. This > looks pretty different to me at first glance, though admittedly I don't live on > Windows. Yeah, we'll need to update those screenshots. This is something we really wanted and planned to fix for the release. I guess there was a lack of communication about that. I'd be glad to help update any materials; do you know whom I should talk to?

Sorry, I'm still a little unclear on the above question: why can't we just copy over the mac voodoo? Were you answering this when you mentioned not wanting the spacing above?

fryn, check with John Slater for product pages at mozilla.com and David Tenser for sumo.

(In reply to comment #34) > Sorry, I'm still a little unclear on the above question: why can't we just copy > over the mac voodoo? Were you answering this when you mentioned not wanting the > spacing above? The border shapes are different, which require different vector paths/shapes when specifying SVG masks. You can't just copy and paste. (In reply to comment #35) > fryn, check with John Slater for product pages at mozilla.com and David Tenser > for sumo. Thanks. Will do.

There is still this non-clickable area above tabs, which should have gone with this fix.

Also tab focus with F6 looks bad.

Looks nice, but new tabs are a bit taller than previous version.

I don't understand how a bug to give tabs more curvature becomes a bug to to make tabs into blocks but fair enough. That said, tabs are far far too tall.

Yes, the tabs look much too tall. For example, hover over the close button of a tab: the close button is closer to the right side of the tab than to the top or bottom by a few pixels. The tabs ought to be of such a height that the close button border should be equidistant from the top, bottom and right-hand edges of the tab, in my opinion.

On behalf MozillaZine community: They are ugly. Period.

I've noticed some usability issues. At a glance before, you'd look for the curve from the tab-line base to the tab. Now such a thing doesn't exist, I'm finding it harder to find the active tab. Can we increase the contrast between foreground and background tabs?

Christ this looks absolutely terrible and adds more vertical pixels to the interface. At least make the tabs a little bit thinner.

This latest change looks reasonable in a restored window under Windows 7 (as per mock-up), however, in a Windows 7 maximized window (the more usual state) the tabs just looks wrong and out of place with tabs in the title bar. The size and curvature of the tabs in beta 12 was more consistent with the curvature of the Firefox button and with the window caption buttons. Perhaps the appearance/height could adjust depending upon whether window is maximized or restored? In a maximized window you don't need such a tall tab due to the infinite top screen edge.

Tabs look like they came straight from Windows 98 now.

(In reply to comment #42) > On behalf MozillaZine community: They are ugly. Period. What purpose was this comment suppose to serve? It's just plain rude.

Since you are going for a more squared look, couldn't you drop the tabs border-radius too? If the cursor is on the top edge of the screen, the clickable area of the tabs is reduced because of this. For example, app tabs have 32px width, but the top edge clickable area is reduced 7px each side because of the border radius; you end with only 18px to click the tab.

(In reply to comment #47) > (In reply to comment #42) > > On behalf MozillaZine community: They are ugly. Period. > > What purpose was this comment suppose to serve? It's just plain rude. Please, ignore that comment, it was a mistake.

(In reply to comment #45) > This latest change looks reasonable in a restored window under Windows 7 (as > per mock-up), however, in a Windows 7 maximized window (the more usual state) > the tabs just looks wrong and out of place with tabs in the title bar. The size > and curvature of the tabs in beta 12 was more consistent with the curvature of > the Firefox button and with the window caption buttons. > > Perhaps the appearance/height could adjust depending upon whether window is > maximized or restored? In a maximized window you don't need such a tall tab due > to the infinite top screen edge. ... as a clarification: although I said the restored window looks "reasonable" with squarer tabs, that doesn't mean that I think they look better. On the contrary - the smaller and rounder tabs in the original Windows mock-ups still look better IMO and more in-line with toolbars etc. I hope that the smaller and rounder tab style can be re-instated in a future release when the devs have time. I also hope that this is indeed a change for a technical reason and not trying to follow some daft fashion set by IE9! (where, unlike Firefox, everything in the interface is more square)

Tab bar is now so ugly, so square and so tall. Thank you.

Why not use the method that Mac uses, but make a few changes: Use border images and masks to get the shape of the tab, same as Mac, but make .tab-background-middle have a top border radius and push .tab-background-start and -end outside the tab and apply a mask to them, give them a set height that doesn't stretch with the tab and position them at the bottom. This would allow the tab to be stretched vertically without the masks distorting (which is the problem on Mac). The other issue is the .new-tab-button. We can't apply a background-color to this because we have nothing to apply masks to. The solution? Add .tab-background to the new tab button as well. Really, there is no reason why the tabs can't be curved. It is entirely doable.

Oops, that should read '.tabs-newtab-button'.

For some reason the tab bar look broken now...

(In reply to comment #52) > Why not use the method that Mac uses, but make a few changes: > > Use border images and masks to get the shape of the tab, same as Mac, but make > .tab-background-middle have a top border radius and push .tab-background-start > and -end outside the tab and apply a mask to them, give them a set height that > doesn't stretch with the tab and position them at the bottom. This would allow > the tab to be stretched vertically without the masks distorting (which is the > problem on Mac). The other issue is the .new-tab-button. We can't apply a > background-color to this because we have nothing to apply masks to. The > solution? Add .tab-background to the new tab button as well. > > Really, there is no reason why the tabs can't be curved. It is entirely doable. Hm.. I was just about to ask how the author of Strata40 managed to get this done. Tabs right now look a lot better than the previous ones, but the mockups sill mock us :'(

Strata40 (the theme, not the style found in Stratiform) used border images for the tabs, like Firefox 4 currently uses, but the difference is the tabs in Firefox 4 need to have editable background colours, so backgrounds and border images need to be used. It gets more complicated. In fact, this is one of the most complicated parts of the entire interface (if not the most).

(In reply to comment #56) > Strata40 (the theme, not the style found in Stratiform) used border images for > the tabs, like Firefox 4 currently uses, but the difference is the tabs in > Firefox 4 need to have editable background colours, so backgrounds and border > images need to be used. It gets more complicated. In fact, this is one of the > most complicated parts of the entire interface (if not the most). what? where is the logical bond between the need to use border-images and the need to have editable background colors?

Border images have to be used to get the curve on the bottom. Background colours need to be used to add colour to the tab (XP will need different coloured tabs compared to Windows 7, etc.). Sure, you could use a whole range of border images for every colour but then it isn't flexible. An add-on can't just change the background colour with CSS. You can't have an irregular shaped background that fills the bottom curves so you have to use masks, but if you use masks you won't be able to scale the tab vertically. It will have a fixed height or else the masks will stretch. Strata40 didn't bother with background colours but then it didn't need to bother with Personas and add-on compatibility (to the same extent). Sure, Mozilla could just use border images but they will get complaints from add-on developers stating that they can't change the colour of the tabs and the file size would increase due to the vast number of tab images required. Mozilla is trying to get away from images as much as possible. In a perfect world we would be using SVGs for the glyphs and tabs and no images would be used. This is not yet possible.

SpewBoy: So the method you mentioned in Comment 52 can't be implanted since it will prevent developers from being able changing tab colors? Is it even possible to redo the tabs in SVG for Windows, or is the problem the time frame that fix would take?

(In reply to comment #58) SpewBoy is correct. Personas are the primary compatibility issue for now. It's not easy to address. Even the tabs on OS X look a bit odd right now with Personas. We'll try to target implementing the SVG curves for Firefox 5, so the tabs on Windows look at least as smooth as the tabs on OS X.

My method would allow the tabs to be coloured and would allow the tabs to be of any height. The main issue is the new tab button, which is just a button so applying masks to it is going to be a bit tricky. It would have to be converted to a tab that acts as a button when clicked. The tabs can't be done effectivelly with SVGs. SVG border images don't work (which would have been the best solution by far) and for some reason stuff like: #SVG-tab:hover { fill: brown; } Does not work in the UI. It will work as a standalone web page but not in a toolbar. This means SVG tabs would need separate SVGs for the hover and selected states, as the colour can't be changed by using selectors like :hover or .tabbrowser-tab[selected] > #SVG-tab. They can only be changed by referring to the SVG directly like #SVG-tab.

I don't get this ugly change between beta 12 -> RC. The beta 12 tabs looked great, and don't see why they couldn't have been left alone. You could have left all the technical SVG etc. fiddling and poking until Firefox 5 rather than this last minute effort. In fact, I would go further and say that in my opinion the beta 12 tabs looked even better than the original mockups, which had a lot of unnecessary little extra curves at the bottom edge. The beta 12 tabs instead resembled better almost an inverted version of the caption buttons and Firefox button with a curved upper edge and straight bottom edge - these blended in much better with the Windows UI!

I should note I also found the b12 tabs more attractive (on Win XP) than the rc1 tabs, but I can live with the rc1 ones; especially if bug 640490 gets solved.

Whatever the UX team did to the tabs between the latest beta and the RC was fantastic. The tabs look a LOT better in Windows 7. Prior to the RC the tabs looked very out of place, now they have a very "polished" feel to them and seem to fit better with the rest of the UI. I suppose the height of the tabs could be reduced a little, but the corners look great.

Verified fixed on Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre

I've come up with a way of adding the curve to the bottom of the tabs, and allowing them to be coloured. Uses SVGs and PNGs as background images, using -moz-calc() to position them. The tab can be of any height / width and of any colour. The attachment is a series of CSS hacks to demonstrate the idea behind this method. It will make your selected tab curve out at the bottom, based on the future Firefox mockups (http://stephenhorlander.com/pages/firefox-future-mockups/button-vs-nobutton-comparison.html). Only real issue with this method is it requires 18 images (9 SVGs, 9 PNGs), but it is by far the most accurate and fool-proof way of adding those curves.

(In reply to comment #66) > Created attachment 527539 [details] > Method for tab curves > > I've come up with a way of adding the curve to the bottom of the tabs, and > allowing them to be coloured. Uses SVGs and PNGs as background images, using > -moz-calc() to position them. The tab can be of any height / width and of any > colour. The attachment is a series of CSS hacks to demonstrate the idea behind > this method. It will make your selected tab curve out at the bottom, based on > the future Firefox mockups > (http://stephenhorlander.com/pages/firefox-future-mockups/button-vs-nobutton-comparison.html). > Only real issue with this method is it requires 18 images (9 SVGs, 9 PNGs), but > it is by far the most accurate and fool-proof way of adding those curves. though it looks nice at first glance - it is sooo wrong: just try to add a nice slim border to that tab (using border:, not with svg). I know a way easier solution: just add 2 small elements - one at left and one at right from tab[selected="true"] and apply a gradient for them with ~45 (and ~-45) degrees angle from transparent color to the fully opaque color. It is also possible to place a middle color between them which would serve us as the border to those triangles (well, actually they might be not just triangles with choppy curves, but slime and rounded, since we can use radial, not linear gradients).

Oh, and as these 2 side elements will have z-index higher than active tab's - then they will lay above (above in z-axis, not y-axis) active tab's borders, so there won't be the active tab's border between them (actually it will be there, but it will be hidden behind those elements).

Or, actually, it can be even a single element, which will lay as a foreground to the active tab, but that will require some color adjust, so it would look like a single element with the active tab.

The solution I posted works with any element in the tab bar, including the .tabs-newtab-button. I can probably simplify it further to either be just one SVG file or one SVG and one PNG, taking advantage of -moz-image-region. This method does not rely on gradients or anything to colour the tab. All you need to do is specify just one colour and it will colour it. Obviously the method would need to be simplified if it was going to be part of the theme, because the code I provided is overriding the default tab code - it's just a hack. Would your method work for a tab of variable height, and would it work for non-tab elements like the new tab button?

Also, how would you add the border to the curve? You can't use gradients for an outwards curve... Unless you use about 9 of them one after the other. Also a small correction: -moz-image-region should be -moz-image-rect.

(In reply to comment #70) > The solution I posted works with any element in the tab bar, including the > .tabs-newtab-button. My solution would easily work with _any_ element you like. > I can probably simplify it further to either be just one > SVG file or one SVG and one PNG, taking advantage of -moz-image-region. How much will it slow down CPU and RAM consumption? Gradient is a function, and PNG/SVG is an image (in case of SVG it is usually image+function). That'd be nice to have a fair comparison. > This > method does not rely on gradients or anything to colour the tab. All you need > to do is specify just one colour and it will colour it. Obviously the method > would need to be simplified if it was going to be part of the theme, because And you could actually code all the graphics into base64 to minimize disk read actions. But currently there is an open bug, that won't let you store SVG in the css style that way. > the code I provided is overriding the default tab code - it's just a hack. That's not a hack, since this is the basics of how CSS (CASCADING) works. That is just a style that overrides another one. That's ok. > Would your method work for a tab of variable height, Yes, since this element can be set as a child to the tab-bar's elements and will always have the same height. > and would it work for non-tab elements like the new tab button? Sure, why not? This would work actually for every button you like. (In reply to comment #71) > Also, how would you add the border to the curve? You can't use gradients for an > outwards curve... Once again: I suggested to have 3 colors as gradients. 1 should be transparent color - that would be the upper part of the squared element which would visually cut it to the triangle (with maybe even rounded lines). 2. would be a 1px height (or using em to draw the border's shadow effect) gradient which actually will serve us as the border. So in case you want to change the border's color/style - you should edit this value. 3. bottom part of the same color as our parental element (be it a tab, or a new-tab-button or whatever it is). > Unless you use about 9 of them one after the other. Way less then 9.

:0 I'd like to see your method in action. I'm intrigued by this, it's not quite clear in my head exactly how you would do this. I can think of ways to do it with gradients, but it would take far more than 3 of them, and you would need to change the colour in each one individually to colour the tab. My rather more refined method (refined from the previous example) allows you to edit one tab PNG image, rather like a border image, to whatever style is necessary, while the SVGs take the role of the colouring. The SVGs and PNG come to a total of 1.54kb. Each SVG is only 3 short lines of code, and the result is 99% pixel perfect to the Firefox mockups.

CSS doesn't allow to create elements, so I can't show you how it would look like.

(In reply to comment #74) > CSS doesn't allow to create elements, so I can't show you how it would look > like. Create a prototype of the feature in a HTML document and attach it to this bug. :)

(In reply to comment #74) > CSS doesn't allow to create elements, so I can't show you how it would look > like. Wait, if you need to create elements, how could this be used with toolbar buttons in the tab bar (new tab button)? No one is going to want to add elements inside toolbar buttons. You can add elements using DOM Inspector (just tell us what to add and where) or you could make a prototype

(In reply to comment #75) > (In reply to comment #74) > > CSS doesn't allow to create elements, so I can't show you how it would look > > like. > > Create a prototype of the feature in a HTML document and attach it to this bug. > :) I would need to copy (In reply to comment #76) > (In reply to comment #74) > > CSS doesn't allow to create elements, so I can't show you how it would look > > like. > > Wait, if you need to create elements, how could this be used with toolbar > buttons in the tab bar (new tab button)? No one is going to want to add > elements inside toolbar buttons. > > You can add elements using DOM Inspector (just tell us what to add and where) > or you could make a prototype Sorry, too lazy to do this. I just dropped an idea. Will you (or anyone else who is to code it) use it or not - I don't care: none of the bugs I opened got fixed. None of the bugs I voted for (and that live for years) got fixed. None of the patches I suggested to my bugs got reviewed. I'm not sure it won't be Sisyphean labour if I bother myself creating a prototype.

Going on and on in a Resolved Fixed bug is certainly not the right approach. If you want to propose a change to Firefox, please don't piggy-back that proposal on a fixed bug. Create a new bug or post a demo to a website or something.

Base on Spewboy's code and Spewboy's Stratiform, I created this style: http://userstyles.org/styles/50806/firefox-4-8-curve-tabs

(In reply to Frank Yan [:fryn] from comment #60) > (In reply to comment #58) > We'll try to target implementing the SVG curves for Firefox > 5, so the tabs on Windows look at least as smooth as the tabs on OS X. If a new Bug# has been filled, Do you happen to know the Bug# ?

(In reply to Frank Yan [:fryn] from comment #60) > (In reply to comment #58) > We'll try to target implementing the SVG curves for Firefox > 5, so the tabs on Windows look at least as smooth as the tabs on OS X. If a new Bug# has been filed, Do you happen to know the Bug# ?

Spewboy figured out a new method of curve tab that doesn't require *.svg It has less code than before and uses only a border image, very simple and easy: http://userstyles.org/styles/50806/firefox-curve-tabs

(In reply to Asa Dotzler [:asa] from comment #78) > Going on and on in a Resolved Fixed bug is certainly not the right approach. > If you want to propose a change to Firefox, please don't piggy-back that > proposal on a fixed bug. Create a new bug or post a demo to a website or > something. I'm still not sure how this bug can be fixed, when the purpose of it is to make the bottom of the selected tab curve into the nav bar. The solution provided basically does the opposite to the original intentions, and does not follow Horlander's mockups. The above method is probably the simplest, and will use less code than the current method used in Windows. It is also much easier to change the tab's colour. Just change the background-color and border-bottom-color and you are good to go. This can be adapted to unselected tabs, too. I'm pretty new to Bugzilla. If I want this to actually go somewhere, even if it is very much to do with this bug, do I still need to make another bug just because someone marked this a fixed?