Sebastian Zartner [:sebo] Reporter
	Description • 11 years ago

In Firebug we lately replaced PNG images by SVG images and use SVG filters on them. In Firefox 24.0a1 (Nightly) we realized that sometimes the buttons inside Firebug won't be shown when the SVG filters are used.

Test case:
1. Install the attached Firebug version in a fresh Firefox Nightly profile
2. Press F12 to open Firebug
3. Click the Close button at the upper right corner of Firebug
4. Press F12 again
5. Hover the Close button

=> It's not displayed anymore.

This just happens on Nightlies and to the regression must have happened between 2013-05-25 and 2013-05-26.
See also the related bug report on the Firebug issue tracker[1]. 

Sebastian

[1] http://code.google.com/p/fbug/issues/detail?id=6536

	Daniel Holbert [:dholbert]
	Comment 1 • 11 years ago

Quoting http://code.google.com/p/fbug/issues/detail?id=6536#c4 :
{
 Last good nightly: 2013-05-25
 First bad nightly: 2013-05-26

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7a2f7a45819a&tochange=0fed3377c839
}

which includes a bunch of svg changes from jwatt; presumably this is a regression from one of those.

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 11 years ago

> => It's not displayed anymore.

That typically means the filter was not valid SVG or for some other reason could not be rendered...

	Sebastian Zartner [:sebo] Reporter
	Comment 3 • 11 years ago

Though it is rendered correctly the first time you hover it. This is just happening after it was clicked the first time.
FWIW the same happens for the other window buttons (the ones in the upper right corner) and for the debugger buttons (inside the Script panel), which have a filter applied. Though it does not happen for other buttons like the e.g. Inspect button (the one with the blue arrow at the left upper side of Firebug), which have the same filter when hovering them.
They are all <toolbarbutton>s having their images defined via "list-style-image".

Sebastian

	Jonathan Watt [:jwatt]
	Comment 4 • 11 years ago

I checked out http://code.google.com/p/fbug/source/checkout and I'm not seeing '<filter ' in there.

Sebastian, could you help me out by pointing me to the relevant Firebug source code? (The filters, and the elements referencing those filters.)

	Sebastian Zartner [:sebo] Reporter
	Comment 5 • 11 years ago

The close button has the ID "fbCloseButton"[1] and the filter[2] is applied via a simple CSS rule[2].

Sebastian

[1] https://github.com/firebug/firebug/blob/f45637ee72133ebf5b2e0dddd06b2b5646358482/extension/content/firebug/firebugOverlay.xul#L128
[2] https://github.com/firebug/firebug/blob/f45637ee72133ebf5b2e0dddd06b2b5646358482/extension/content/firebug/firebugui/filters.svg
[3] https://github.com/firebug/firebug/blob/f45637ee72133ebf5b2e0dddd06b2b5646358482/extension/skin/classic/win/firebug.css#L115

	Sebastian Zartner [:sebo] Reporter
	Comment 6 • 11 years ago

> simple CSS rule[2]
Should have been [3] of course.

Sebastian

	bhavana bajaj [:bajaj]
	Comment 7 • 11 years ago

Adding needsinfo on :jwatt to confirm the issue based on information in comment#5 & 6

	Jonathan Watt [:jwatt]
	Comment 8 • 11 years ago

Bah. It seems I fell into the trap of reading old unmaintained MDN docs pointing to a defunct SVN repo, since that was the top Google result for "Firebug source". I've fixed the MDN page now, and I'll look at this again in a few days when I clear a bit of time.

	Sebastian Zartner [:sebo] Reporter
	Comment 9 • 11 years ago

> It seems I fell into the trap of reading old unmaintained MDN docs pointing to a 
> defunct SVN repo
Yeah, we moved to github at the beginning of last year. Sorry for not explicitly mentioning where the current code can be found.

Sebastian

	Jonathan Watt [:jwatt]
	Comment 10 • 11 years ago

I've not been able to extract a working testcase to debug out from the Firebug code, and since Firebug has since worked around this problem and we haven't had any other related reports I don't think we should track. Resetting tracking flags to "?" to see if releng agree.

	Jonathan Watt [:jwatt]
	Comment 11 • 11 years ago

Also note that the issue is with XUL, so this may not be an issue for web content.

The Firebug workaround is detailed here:

http://code.google.com/p/fbug/issues/detail?id=6536#c12

	Sebastian Zartner [:sebo] Reporter
	Comment 12 • 11 years ago

> The Firebug workaround is detailed here:
> 
> http://code.google.com/p/fbug/issues/detail?id=6536#c12

Note that this is just a temporary workaround, so we could release the next version of Firebug without waiting for this issue to be fixed.

> I've not been able to extract a working testcase to debug out from the Firebug 
> code
Isn't my test case from comment 0 enough? Do you need something else from me?

Sebastian

	Jonathan Watt [:jwatt]
	Comment 13 • 11 years ago

(In reply to Sebastian Zartner from comment #12)
> Note that this is just a temporary workaround, so we could release the next
> version of Firebug without waiting for this issue to be fixed.

I see.

> Isn't my test case from comment 0 enough? Do you need something else from me?

I don't see a testcase in comment 0, just a series of steps to reproduce the issue in the live app. A testcase would be a small file with the minimum amount of content to reproduce the issue.

	Jonathan Watt [:jwatt]
	Comment 14 • 11 years ago

Sebastian, can someone on the Firebug side maybe reduce the issue down to a single, smallish XUL file? This addon will likely come in handy for that:

https://addons.mozilla.org/en-US/firefox/addon/remote-xul-manager/

	Sebastian Zartner [:sebo] Reporter
	Comment 15 • 11 years ago

I'll try to find one. Honza, maybe you can also have a look and search for a test case.

Sebastian

	Jan Honza Odvarko [:Honza] (always need-info? me)
	Comment 16 • 11 years ago

(In reply to Sebastian Zartner from comment #15)
> Honza, maybe you can also have a look and search for a test case.
Test case committed and available here:
https://github.com/firebug/manual-tests/tree/master/mozilla/bug886883

I am also attaching an xpi build.

STR:

1) Install the extension into an empty Firefox profile
2) You should see a new grey area at the bottom of the browser window (the same place Firebug usually takes).
3) Click the red button at the top-left corner of the area, it should close it.
4) Press F12 to open it again
5) Move mouse over the red button it disappears -> BUG

Can you see the problem?

Honza

	Sebastian Zartner [:sebo] Reporter
	Comment 17 • 11 years ago

You're a genius, Honza!
I was working on a similar test extension, though it would have taken me some more time to finish it.

Sebastian

	bhavana bajaj [:bajaj]
	Comment 18 • 11 years ago

Jwatt, what are the next steps here given comment #16 ?

	Jonathan Watt [:jwatt]
	Comment 19 • 11 years ago

I'll be looking into it soon; today hopefully.

	Jan Honza Odvarko [:Honza] (always need-info? me)
	Comment 20 • 11 years ago

Slightly modified version of the extension attached in comment #16

Use it if you testing on Mac and want to avoid F12

This version uses cmd+shift+e instead

Honza

	Jonathan Watt [:jwatt]
	Comment 21 • 11 years ago

I've spent quite a lot of time running down some deadends debugging this. The chances of getting a patch for v24 are very small to none. I think we should wontfix this for v24, and Firebug will have to keep their workaround in place until v25 comes around.

	Alex Keybl [:akeybl]
	Comment 22 • 11 years ago

(In reply to Jonathan Watt [:jwatt] from comment #21)
> I've spent quite a lot of time running down some deadends debugging this.
> The chances of getting a patch for v24 are very small to none. I think we
> should wontfix this for v24, and Firebug will have to keep their workaround
> in place until v25 comes around.

Where do we stand on resolving this for FF25 in that case?

	Jonathan Watt [:jwatt]
	Comment 23 • 11 years ago

(In reply to Jan Honza Odvarko from comment #20)
> Created attachment 797265 [details]
> Test extension v2
> 
> Slightly modified version of the extension attached in comment #16

This is WFM in current beta, aurora and nightly. Anyone care to track down what fixed it?

	Jonathan Watt [:jwatt]
	Comment 24 • 11 years ago

Actually beta is still affected.

	juan becerra [:juanb]
	Comment 25 • 11 years ago

The problem was present in a build from 8/25 and gone away in a build from 8/26. Something here fixed it:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=01576441bdc6&tochange=4887845b1142

There are few fixes that look suspicious like bug 908880 bug 879682, but I'm guessing.

	Jonathan Watt [:jwatt]
	Comment 26 • 11 years ago

Almost certainly bug 908880 - checking.

	Jonathan Watt [:jwatt]
	Comment 27 • 11 years ago

Applying the patch for bug 908880 to beta branch fixes this bug there. I'll request approval for beta over on that bug based on that.

	Jan Honza Odvarko [:Honza] (always need-info? me)
	Comment 28 • 11 years ago

Jonathan: do you still want me to update the extension, so it's easier to test?
It looks like the bug is resolved...

Honza

	Jonathan Watt [:jwatt]
	Comment 29 • 11 years ago

Honza, no need (pinged you on IRC last night, but I guess you didn't get that).

	u279076
	Comment 30 • 11 years ago

Pre-emptively adding verifyme to test the fix once it gets uplifted to Beta.

	Sebastian Zartner [:sebo] Reporter
	Comment 31 • 11 years ago

I can confirm that it's working on the current (2013-10-15) Aurora and Nightly build.
Seems like I can finally get the new SVG icons for Firebug back. Thanks for the efforts!

Sebastian

	Jonathan Watt [:jwatt]
	Comment 32 • 11 years ago

The patch in 908880 has been given approval-mozilla-beta- for being too late in the cycle, so this is status-firefox25:wontfix.

To reiterate, Firefox 26 and above are fixed.

	Jonathan Watt [:jwatt]
	Comment 33 • 11 years ago

Fixed by bug 908880.

	u279076
	Comment 34 • 11 years ago

Verified fixed based on comment 31.