If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

UI regression for toolbox toolbars and tabs on Windows since bug 941673

VERIFIED FIXED in Firefox 28

Status

()

Firefox
Developer Tools: Framework
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: Optimizer, Assigned: bgrins)

Tracking

(Blocks: 1 bug)

unspecified
Firefox 29
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox28 verified, firefox29 verified)

Details

Attachments

(3 attachments, 4 obsolete attachments)

(Reporter)

Description

4 years ago
Created attachment 8343870 [details]
windows.jpg

Since osx and windows styles were merged. Osx's styles were forced onto Windows. While in terms of colors they might be similar for most cases, there are a lot of things different in the defaults of windows and osx and also other minor stuff.

See the screenshot which lists out most of them.
(Reporter)

Updated

4 years ago
Blocks: 941673
(Reporter)

Comment 1

4 years ago
Created attachment 8343873 [details]
one more diff

One more difference in style editor. See the new and import buttons
(Assignee)

Comment 2

4 years ago
(In reply to Girish Sharma [:Optimizer] from comment #0)
> Created attachment 8343870 [details]
> windows.jpg
> 
> Since osx and windows styles were merged. Osx's styles were forced onto
> Windows. While in terms of colors they might be similar for most cases,
> there are a lot of things different in the defaults of windows and osx and
> also other minor stuff.
> 
> See the screenshot which lists out most of them.

FWIW, it was mostly Linux styles that were copied onto Windows, not OSX.  Thanks for taking the screenshot and listing out the issues.  We should be able to handle platform specific issues with preprocessor directives when needed, but I would hope that we can avoid these as much as possible.  Things like this weird outline on dock to side and the splitter color should definitely be resolved.

Generally, how important are the things like the rounded input and gradient for selected buttons, beyond personal preference?  I think with the new theme, we are targeting a consistent style rather than different depending on the OS - but maybe not.
(Reporter)

Comment 3

4 years ago
(In reply to Brian Grinstead [:bgrins] from comment #2)
> FWIW, it was mostly Linux styles that were copied onto Windows, not OSX. 
> Thanks for taking the screenshot and listing out the issues.  We should be
> able to handle platform specific issues with preprocessor directives when
> needed, but I would hope that we can avoid these as much as possible. 
> Things like this weird outline on dock to side and the splitter color should
> definitely be resolved.
> 
> Generally, how important are the things like the rounded input and gradient

It is exactly like using a square input box on osx. Odd one out. not even a single input box in firefox has rounded borders like that for Windows. Also, rounded borders are only on osx. So this will be inconsistent input boxes design for both windows and linux.

> for selected buttons, beyond personal preference?  I think with the new

For one, we are aiming towards a flatter design. This curved gradient was present only in osx, not even on linux. Doesn't make sense to replace windows and linux with what was on osx.

> theme, we are targeting a consistent style rather than different depending
> on the OS - but maybe not.

Yes, and that consistent should be one step towards the final design, not a step backwards :)

Also, I don't think that we can avoid being platform specific in case of input boxes at least. Just like I hate these out of place rounded boxes on windows, osx users will hate the square boxes :)
(Assignee)

Comment 4

4 years ago
(In reply to Girish Sharma [:Optimizer] from comment #3)
> (In reply to Brian Grinstead [:bgrins] from comment #2)
> > FWIW, it was mostly Linux styles that were copied onto Windows, not OSX. 
> > Thanks for taking the screenshot and listing out the issues.  We should be
> > able to handle platform specific issues with preprocessor directives when
> > needed, but I would hope that we can avoid these as much as possible. 
> > Things like this weird outline on dock to side and the splitter color should
> > definitely be resolved.
> > 
> > Generally, how important are the things like the rounded input and gradient
> 
> It is exactly like using a square input box on osx. Odd one out. not even a
> single input box in firefox has rounded borders like that for Windows. Also,
> rounded borders are only on osx. So this will be inconsistent input boxes
> design for both windows and linux.
> 

Fair enough - we can add rounded corners only in the case for OSX.

> > for selected buttons, beyond personal preference?  I think with the new
> 
> For one, we are aiming towards a flatter design. This curved gradient was
> present only in osx, not even on linux. Doesn't make sense to replace
> windows and linux with what was on osx.
> 

Yes, we are aiming towards a flatter design, but the old Windows one isn't matching the new themes, either.  Also, the rest of the toolbars aren't updated yet (look at things like the breadcrumbs and inspect element button).  I opened Bug 942292 for updating the toolbar styles based on the new designs.

Regarding the changes to make it look better on Windows, are you able to help with this?  I can do it, but it will be slow, since I need to push to try to check changes.  Plus you will have a better idea of what things should look like.  I will attach a patch that at least updates the border radius on inputs, let me know if you want me to track down the other issues.
(Assignee)

Comment 5

4 years ago
Created attachment 8343925 [details] [diff] [review]
theme-windows.patch

Does this fix the input problem?
Attachment #8343925 - Flags: feedback?(scrapmachines)
(Assignee)

Comment 6

4 years ago
Created attachment 8343932 [details] [diff] [review]
theme-windows-splitter.patch

Does this fix the white horizontal splitter problem in the original screenshot?  Looking at the diff from https://bugzilla.mozilla.org/attachment.cgi?id=8341091&action=diff this may resolve that issue.
Attachment #8343932 - Flags: feedback?(scrapmachines)

Comment 7

4 years ago
The tabs are also way bigger because if this bug.
The spliter that seperates the rule view and the markup panel in the inspector used to be lighter before the update, now it's all black.
The prettify icon in the debugger isn't properly aligned in the button too.
The command buttons also have the weird border state too.
The breadcrumbs seem to look quite weird too.
Many things are broken anyways.
(Assignee)

Comment 8

4 years ago
(In reply to ntim007 from comment #7)
> The tabs are also way bigger because if this bug.
> The spliter that seperates the rule view and the markup panel in the
> inspector used to be lighter before the update, now it's all black.
> The prettify icon in the debugger isn't properly aligned in the button too.
> The command buttons also have the weird border state too.
> The breadcrumbs seem to look quite weird too.
> Many things are broken anyways.

I understand that things don't look the same.  Do not fear - we are going to fix any regressions and make sure it lands in Aurora.  I am considering regressions in this case to be obvious visual glitches or things that break native UI standards.

It is important that we make the distinction between these things and things that just look different now, since we are going through some redesigns in Bug 916766.  Here is the list of things that need to be fixed in this bug from my point of view:

* Rounded corners on text boxes.
* Splitter above devtools has a background color.
* Weird border state on command buttons.
* The prettify icon in the debugger isn't properly aligned in the button

Things that I think should be done elsewhere, or I don't fully understand from the descriptions:

* "The tabs are also way bigger because if this bug."  I'm not seeing this in Optimizer's screenshot.
* "The breadcrumbs seem to look quite weird."  Not sure exactly what this means, but maybe this is an artifact of copying over the Linux styles.  These are going to be updated in Bug 936421 anyway.
* There are now gradients in buttons for style editor and filters for console.  These styles are going to be updated in Bug 942292.
* "Many things are broken anyways."  What else is broken?

Comment 9

4 years ago
The two first problems, I'll share a screenshot.
Other things :
- The splitter in the Variables view is horrible (similar to the top toolbox splitter)
- There seem to be less padding in the console menu button (the toggles) dropdowns.
- The selected toolbox tab icon is no longer "opacity:1" (it can be seen in optimizer's screenshot)

There are many minor differences, but I guess it's gonna be fixed with the new designs.

Comment 10

4 years ago
Oh yeah, forgot, the search boxes no longer have a focus state (they used to have a blue border on focus)

Comment 11

4 years ago
Also, even without the ugly splitters, the toolbox top border and the variables view in debugger are lighter than they used to be, instead of black, they are gray.
(Assignee)

Comment 12

4 years ago
> - The selected toolbox tab icon is no longer "opacity:1" (it can be seen in
> optimizer's screenshot)

This is affecting all OSes, and can be fixed with a line in the toolbox.css like this: https://bugzilla.mozilla.org/attachment.cgi?id=8343971&action=diff#a/browser/themes/shared/devtools/toolbars.inc.css_sec2.  We should include this fix in here as well.

Comment 13

4 years ago
A fix for the huge style editor buttons would also be nice. It is shown in optimizers 2nd screen.

Comment 14

4 years ago
In your patch there seem to be a duplicated rule for .devtools-side-splitter, you readded background-color:transparent;
(Assignee)

Comment 15

4 years ago
(In reply to Tim Nguyen [:ntim] from comment #14)
> In your patch there seem to be a duplicated rule for
> .devtools-side-splitter, you readded background-color:transparent;

Ah, I see that now.  Are you able to confirm that the patch fixes the problem with the splitter color and the rounded corners on the text boxes?

Comment 16

4 years ago
(In reply to Brian Grinstead [:bgrins] from comment #15)
> (In reply to Tim Nguyen [:ntim] from comment #14)
> > In your patch there seem to be a duplicated rule for
> > .devtools-side-splitter, you readded background-color:transparent;
> 
> Ah, I see that now.  Are you able to confirm that the patch fixes the
> problem with the splitter color and the rounded corners on the text boxes?

Well, in theory it should, but why does the second patch include the first patch ? You should mark the first one as obsolete. 
Anyways, found another bug, the developer toolbar's styling is broken (even in safe mode)

Comment 17

4 years ago
Btw Brian, this is totally unrelated, but how do I get the debugger resumption order panel to be shown (to fix my first bug). To be honest, I never use the debugger. I asked on IRC, but no one answered.
(Assignee)

Comment 18

4 years ago
(In reply to Tim Nguyen [:ntim] from comment #17)
> Btw Brian, this is totally unrelated, but how do I get the debugger
> resumption order panel to be shown (to fix my first bug). To be honest, I
> never use the debugger. I asked on IRC, but no one answered.

Tim,
What is the bug number?  If it is a first bug, it should hopefully have a mentor who you can ask in the bug for help.

Comment 19

4 years ago
There's already a mentor (Victor Porof), but I'm just taking advantage of the fact that you're online so I can get an earlier response.
Here's the bug number : bug 947143

Comment 20

4 years ago
(In reply to Tim Nguyen [:ntim] from comment #19)
> There's already a mentor (Victor Porof), but I'm just taking advantage of
> the fact that you're online so I can get an earlier response.
> Here's the bug number : bug 947143

(Please discuss this in the relevant bug or on IRC)

Comment 21

4 years ago
(In reply to Brian Grinstead [:bgrins] from comment #4)
> (In reply to Girish Sharma [:Optimizer] from comment #3)
> > (In reply to Brian Grinstead [:bgrins] from comment #2)
> > > FWIW, it was mostly Linux styles that were copied onto Windows, not OSX. 
> > > Thanks for taking the screenshot and listing out the issues.  We should be
> > > able to handle platform specific issues with preprocessor directives when
> > > needed, but I would hope that we can avoid these as much as possible. 
> > > Things like this weird outline on dock to side and the splitter color should
> > > definitely be resolved.
> > > 
> > > Generally, how important are the things like the rounded input and gradient
> > 
> > It is exactly like using a square input box on osx. Odd one out. not even a
> > single input box in firefox has rounded borders like that for Windows. Also,
> > rounded borders are only on osx. So this will be inconsistent input boxes
> > design for both windows and linux.
> > 
> 
> Fair enough - we can add rounded corners only in the case for OSX.

So,

> not even a single input box in firefox has rounded borders like that for Windows

You can't use this argument :) 90% of the design of the toolbox can't be found on Windows and Mac (black tabs, floating scrollbars, …).

Let's not choose between Windows and Mac, or use preprocessing instructions to get different styles, let's find a design that works for the toolbox across the platforms. We should use as less as possible specific styles (maintenance is hard).
(Reporter)

Comment 22

4 years ago
Then I say we go with the (previously) majority case of square input boxes :)

Comment 23

4 years ago
(In reply to Girish Sharma [:Optimizer] from comment #22)
> Then I say we go with the (previously) majority case of square input boxes :)

Why? And how do you count? (majority?) I'll delegate that to UX.

Comment 24

4 years ago
Darrin, halp!, we need a search box design that works across the 3 platforms.
Flags: needinfo?(dhenein)
(Reporter)

Comment 25

4 years ago
(In reply to Paul Rouget [:paul] from comment #23)
> (In reply to Girish Sharma [:Optimizer] from comment #22)
> > Then I say we go with the (previously) majority case of square input boxes :)
> 
> Why? And how do you count? (majority?) I'll delegate that to UX.

I count by both 2 out of three tiers (Windows and Linux had square border) and majority of users (Windows + Linux make more than 70% of Firefox users)

Updated

4 years ago
Blocks: 916766
(Assignee)

Updated

4 years ago
Attachment #8343925 - Attachment is obsolete: true
Attachment #8343925 - Flags: feedback?(scrapmachines)
(Assignee)

Comment 26

4 years ago
Created attachment 8344719 [details] [diff] [review]
theme-windows-fixes.patch

This should fix the splitter, button hover, and pretty print alignment.  Can you confirm?
Assignee: nobody → bgrinstead
Attachment #8343932 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8343932 - Flags: feedback?(scrapmachines)
Attachment #8344719 - Flags: feedback?(scrapmachines)
(Reporter)

Comment 27

4 years ago
Comment on attachment 8344719 [details] [diff] [review]
theme-windows-fixes.patch

Review of attachment 8344719 [details] [diff] [review]:
-----------------------------------------------------------------

See the screenshot [0] . While the button borders on hover are fine. The horizontal splitter is still 1 px white. It should be transparent, as it was previously [1].

Also, the pretty print button is still not aligned. Looks like the rules debugger.css are being overridden by the ones in dark-theme.css
Also, the Style editor's buttons are still weirdly big .


[0] http://i.snag.gy/20VIC.jpg
[1] http://mxr.mozilla.org/mozilla-aurora/source/browser/themes/windows/devtools/common.css#221
Attachment #8344719 - Flags: feedback?(scrapmachines) → feedback-
(Assignee)

Comment 28

4 years ago
(In reply to Girish Sharma [:Optimizer] from comment #27)

> See the screenshot [0] . While the button borders on hover are fine. The
> horizontal splitter is still 1 px white. It should be transparent, as it was
> previously [1].
> 

Hmm, this is the same rule I've added to the patch: https://bugzilla.mozilla.org/attachment.cgi?id=8344719&action=diff#a/browser/themes/shared/devtools/common.css_sec2 versus: http://mxr.mozilla.org/mozilla-aurora/source/browser/themes/windows/devtools/common.css#221.  This seemed to fix it for me when testing with DOM inspector on nightly.

> Also, the pretty print button is still not aligned. Looks like the rules
> debugger.css are being overridden by the ones in dark-theme.css

Weird, setting font-weight: normal seemed to fix it for me when testing with DOM inspector on nightly.  But I can mess around with it some more.

> Also, the Style editor's buttons are still weirdly big.

I see this now - it looks like it's not so much that the buttons are big but that the toolbar they are in is small.
(In reply to Girish Sharma [:Optimizer] from comment #27)
> Comment on attachment 8344719 [details] [diff] [review]
> theme-windows-fixes.patch
> 
> Review of attachment 8344719 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> See the screenshot [0] . While the button borders on hover are fine. The
> horizontal splitter is still 1 px white. It should be transparent, as it was
> previously [1].
> 

It wasn't previously transparent. It was black.
(Reporter)

Comment 30

4 years ago
(In reply to Victor Porof [:vp] from comment #29)
> It wasn't previously transparent. It was black.

Black was the border color. The background color was transparent. See the [1] link in #27

Comment 31

4 years ago
(In reply to Girish Sharma [:Optimizer] from comment #25)
> > Why? And how do you count? (majority?) I'll delegate that to UX.
> 
> I count by both 2 out of three tiers (Windows and Linux had square border)
> and majority of users (Windows + Linux make more than 70% of Firefox users)

You're making the assumption that the devtools users are represented the same way as the firefox users. I don't think it's true. I actually think nothing. I just don't know :)
(Reporter)

Comment 32

4 years ago
No, I was not talking about the usage of devtools here. I was pointing to the fact that which type of input boxes will be at home to more users. Nothing to do with devtools. But if we use same style across all os'es why not choose the input boxes style which is at home to more number of users.

Also, if we really want, we can try to figure out the distribution of devtools users via our telemetry results :)
(Reporter)

Comment 33

4 years ago
(apparently, either telemetry does not give user os information, or I am unable to figure out the telemetry dashboard that we have)
Here's my 2 cents: I think as long as we are developing our own UI guidelines within the devtools that don't adhere to the OS guidelines (our dark flat theme, top tab bar, etc. as Paul mentioned above) I think an input box which is consistent with *our* devtools UI is more important than trying to tweak individual pieces of our UI to resemble the OS chrome. If we can develop and deliver a consistent experience *within* our tools and toolbox, I think the user will have no issues.

Not as a perfect example, but look at Adobe's suite of applications... they appear very similarly/consistently across Windows, OSX, etc. and have their own (instantly recognizable and usable) UI paradigms. We are not the first people to do this.

To answer the original question, I think we universally use the styled, rounded text inputs as they appear in shorlander's mockup.
Flags: needinfo?(dhenein)
(Assignee)

Comment 35

4 years ago
Created attachment 8345503 [details] [diff] [review]
theme-windows-fixes.patch

OK, I believe that I have tracked down the main remaining issues:
* Style editor buttons should be resized and smaller in both width and height now
* Had to use -moz-border-top-colors to get rid of the white border on the horizontal splitter (go figure)
* Pretty print button should be center aligned again - removed margin on  .toolbarbutton-icon

Can you please have a look and see if the issues above are resolved for you?  Note: I've also reverted to the rounded border to match the comps as mentioned in Comment 34.
Attachment #8344719 - Attachment is obsolete: true
Attachment #8345503 - Flags: ui-review?(scrapmachines)
So I spent some time yesterday getting a few opinions (esp. from people more familiar with Windows design patterns) and after sleeping on it, I want to change my answer to the rounded inputs question. I think while maintaining a consistent UI across platforms is important for many reasons, as shorlander put it "you have to know when to break the rules" to provide something comfortable to the user. Rounded inputs seem natural only on OSX, and so I would like to keep them rounded there but use the (slightly rounded) square corners on Windows and Linux.

bgrins, I saw you just reverted this change... I hope its not a pain to re-revert it ;)
(Assignee)

Comment 37

4 years ago
(In reply to Darrin Henein [:darrin] from comment #36)
> So I spent some time yesterday getting a few opinions (esp. from people more
> familiar with Windows design patterns) and after sleeping on it, I want to
> change my answer to the rounded inputs question. I think while maintaining a
> consistent UI across platforms is important for many reasons, as shorlander
> put it "you have to know when to break the rules" to provide something
> comfortable to the user. Rounded inputs seem natural only on OSX, and so I
> would like to keep them rounded there but use the (slightly rounded) square
> corners on Windows and Linux.
> 
> bgrins, I saw you just reverted this change... I hope its not a pain to
> re-revert it ;)

It's no problem - I will add it back on the next version once I get the ui review on the current patch from Optimizer.
(Reporter)

Comment 38

4 years ago
Comment on attachment 8345503 [details] [diff] [review]
theme-windows-fixes.patch

Review of attachment 8345503 [details] [diff] [review]:
-----------------------------------------------------------------

Everything else is fixed and I like the Style Editor well padded buttons now :)

A few things :

 - Even though this might not be a regressions, the tabs toolbar's bottom border color in the new design of the toolbox tabs is lighter now. which makes it look weird (along with the shadow in place) in options panel in the dark theme. (http://snag.gy/QlMNK.jpg)
 - The control buttons (docking button + close button) still have weird border on hover.
 - You can use the following non moz prefixed way to achieve the splitter top border:

border: 1px solid black;
border-width: 1px 0 0;


(or any other color than black, if you want)
Attachment #8345503 - Flags: ui-review?(scrapmachines)
(Assignee)

Comment 39

4 years ago
Created attachment 8345952 [details] [diff] [review]
theme-windows-fixes.patch

I believe this updates the following:

 - Re adds the non-rounded corners on the textboxes
 - The control buttons (docking button + close button) should not have a border anymore
 - Uses non moz prefixed way to achieve the splitter top border
Attachment #8345503 - Attachment is obsolete: true
Attachment #8345952 - Flags: ui-review?(scrapmachines)
(Assignee)

Comment 40

4 years ago
Comment on attachment 8345952 [details] [diff] [review]
theme-windows-fixes.patch

Review of attachment 8345952 [details] [diff] [review]:
-----------------------------------------------------------------

Joe,
Can you review the changes here?  Even though we are awaiting final confirmation that all issues are resolved in Windows, there shouldn't be any more big changes.
Attachment #8345952 - Flags: review?(jwalker)
Comment on attachment 8345952 [details] [diff] [review]
theme-windows-fixes.patch

Review of attachment 8345952 [details] [diff] [review]:
-----------------------------------------------------------------

The CSS changes look good to me, I'm going to assume that Optimizer is going to do a UI review, but I'm happy to have a look if he doesn't.
Attachment #8345952 - Flags: review?(jwalker) → review+
(Reporter)

Comment 42

4 years ago
Comment on attachment 8345952 [details] [diff] [review]
theme-windows-fixes.patch

Review of attachment 8345952 [details] [diff] [review]:
-----------------------------------------------------------------

All the regressions are fixed now :)

Although I do noticed an issue which is a regression of the new toolbox tabs design (bug 941579)

See the screenshot[0]. The top blue glow is only 1 px visible. It is actually 1px high, but 1 px is behind the splitter. As per spec [1], 2px should be visible so the height needs to be either 3px, or we should move the splitter 1 px up. But that will make the splitter overlap the content of the page.

This can be done in a followup.

[0] http://i.snag.gy/OY9TV.jpg 
[1] https://people.mozilla.org/~shorlander/mockups/devTools/ux-refresh-2013/DarkTheme-Console-AllToggled@2x.png
Attachment #8345952 - Flags: ui-review?(scrapmachines) → ui-review+
(Assignee)

Comment 43

4 years ago
(In reply to Joe Walker [:jwalker] from comment #41)
> The CSS changes look good to me, I'm going to assume that Optimizer is going
> to do a UI review, but I'm happy to have a look if he doesn't.

(In reply to Girish Sharma [:Optimizer] from comment #42)
> All the regressions are fixed now :)

Great, thanks for the reviews!

> Although I do noticed an issue which is a regression of the new toolbox tabs
> design (bug 941579)
> 
> See the screenshot[0]. The top blue glow is only 1 px visible. It is
> actually 1px high, but 1 px is behind the splitter. As per spec [1], 2px
> should be visible so the height needs to be either 3px, or we should move
> the splitter 1 px up. But that will make the splitter overlap the content of
> the page.
> 
> This can be done in a followup.
> 
> [0] http://i.snag.gy/OY9TV.jpg 
> [1]
> https://people.mozilla.org/~shorlander/mockups/devTools/ux-refresh-2013/
> DarkTheme-Console-AllToggled@2x.png

I agree - let's do this in a follow up.
(Assignee)

Comment 44

4 years ago
https://hg.mozilla.org/integration/fx-team/rev/defc9b99115f
https://tbpl.mozilla.org/?tree=Fx-Team&rev=defc9b99115f
(Assignee)

Updated

4 years ago
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/defc9b99115f
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 29

Comment 46

4 years ago
The patch in bug 941673 was landed in Firefox 28, so I guess, this patch should also be in Firefox Aurora 28.
Flags: needinfo?(bgrinstead)
(Assignee)

Comment 47

4 years ago
Comment on attachment 8345952 [details] [diff] [review]
theme-windows-fixes.patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 941673
User impact if declined: There will be a few UI regressions in inside of DevTools on Windows in 28.
Testing completed (on m-c, etc.): Been on m/c since 12/12.  The UI fixes have been reviewed.
Risk to taking this patch (and alternatives if risky): This is a CSS-only change limited to DevTools users.
String or IDL/UUID changes made by this patch:
Attachment #8345952 - Flags: approval-mozilla-aurora?
Flags: needinfo?(bgrinstead)
Attachment #8345952 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/5e2fdd0ab731
status-firefox28: --- → fixed
status-firefox29: --- → fixed
Girish, please confirm this is working for you now in Firefox 28 and 29.
Flags: needinfo?(scrapmachines)
(Reporter)

Comment 50

4 years ago
Yup.
Status: RESOLVED → VERIFIED
Flags: needinfo?(scrapmachines)
(Reporter)

Updated

4 years ago
status-firefox28: fixed → verified
status-firefox29: fixed → verified
You need to log in before you can comment on or make changes to this bug.