Closed Bug 275254 Opened 20 years ago Closed 17 years ago

SVG used in XUL button is not active

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jay, Unassigned)

Details

Attachments

(2 files)

simple XUL button with SVG
836 bytes, application/vnd.mozilla.xul+xml
Details
an svg button with height and width attributes, but no action
861 bytes, application/vnd.mozilla.xul+xml
Details 
It should be possible to use SVG graphics within an XUL button.
The attachment demonstrates that (at least for this code) this isn't currently
possible, as whilst the SVG is displayed, and the label (tooltip or title)
attribute does display on mouseover, the SVG isn't active as a button, the label
element text isn't associated with it, and there is a large active area.

SVG is said to be enetring the trunk in 2005, it would be great if that meant
SVG worked throughout XUL :-)

Our users are pre-literate, they cannot read and need symbols. SVG offers huge
advantages over tradional icons used in buttons. They also need much larger
buttons than most users. http://www.peepo.co.uk uses SVG and demonstrates the
type of preferred interface.

An alpha web browser based on IE and sponsored by European Commission funding
can be seen here: http://80.60.189.118/wwaac/ a product from the
World-Wide Augmentative and Alternative Communication project

it would be great if mozilla XUL is in a condition to compete with this product.
my apologies if this is just poor coding, rather than a bug. ~:"
You need to specify width and height on the <svg> element.
Assignee: nobody → general
Component: XP Toolkit/Widgets: XUL → SVG
QA Contact: ian
Thanks Alex,

that solves one part of the issue, but the svg is still not active "oncommand"
and the relation with 'label' may need to be clarified.


not sure whether label should also raise tooltip....
does in mozilla, but code may well be different...
I'm seeing this with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050429
Firefox/1.0+


Clicking on the SVG causes the button to appear depressed, and also focuses it.
But there is not alert, whereas clicking elsewhere on the button does create an
alert.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Still no alert with second testcase on SeaMonkey 1.0a
I can't help that no one is working on this bug
Seems fixed on trunk. No idea when it happened though.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060319 Firefox/1.6a1
Re: #9

the SVG area of the button isn't active in either attachment, so this bug isn't fixed, please confirm.

apologies if summary isn't descriptive enough :-)

regards
Clicking on the green square in attachment #2 [details] [diff] [review] raises the alert. Don't see tooltips at all. Attachment #1 [details] [diff] gives me strange results. Is there something else to test?
re #9

please can you provide the OS and version that works for you?

example 2:
win'98 ff1.5.0.1 clicking in the green box doesn't work for me, only the background raises dialogue
os X 10.4 ff1.5.0.1 clicking in the green box doesn't work for me, only the background raises dialogue

example 1:
win'98 ff1.5.0.1 clicking in the green box works for me, in the green box or the background
os X 10.4 ff1.5.0.1 clicking in the green box doesn't work for me, only the background raises dialogue

so only one out of the four test cases passes.
I'm using trunk builds on Windows XP. UA String is in comment #9. Although today I'm updated to: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060321 Firefox/1.6a1. Still works.

Both examples somehow have the ability to resize my window. I don't know if unpriveledged XUL is supposed to be able to do that or not, but it does.

Example 1.) The button takes up the entire workspace initially. Probably because of the unrestricted size on the SVG. Clicking on it causes the SVG to disappear, and the window to redraw (resizing again), leaving just the button with text, which then works.

#2.) Works without hiccups.

Sorry if this is bugspam. I can post a link to the example over on the forums and see if it's a fluke of mine or not. Maybe I'm nuts. It's on trunk though (cairo builds). Haven't tested branch.
Example 1 is just weird for me in Linux using Fx2.0 so I'm ignoring it for now.  

Example 2 scenarios:
a) when I press down on the XUL button, the button shows as pressed in, when I release the mouse button on the XUL button, I see "Hello world"
b) when I press down on the XUL button, the button shows as pressed in, when I release the mouse button on the SVG area, nothing happens
c) when I press down on the SVG button, the button shows as pressed in, when I release the mouse button on the SVG button, nothing happens
d) when I press down on the SVG button, the button shows as pressed in, when I release the mouse button on the XUL button, nothing happens

So here's what I'm guessing:

- the mousedown event is passing through the SVG document and up to the XUL container properly (causing the pressed-in effect on the XUL button)
- the mouseup event is passing through the SVG document and up to the XUL container properly (causing the pressed-in effect to go away)
- somehow even though both mouse events are being propagated to the XUL button, the "command" event is not being generated.  It's like the command event only happen if both events originated on the XUL element?  But it seems like the button should fire the command event if both mouse events happened on itself or any of its child elements (even if they are SVG elements).

First, can we answer whether the XUL+SVG document _should_ work?  If not, is there some modification that must be done to generate the commadn event at the XUL button?

If it's correct, any XUL experts here to tell whether this is a XUL bug? 
reviewing this bug, it seems it may be at least related if not dependent on bug 349836

jwatt has also resolved bug 267664 which may alter things once checked in.

also I notice that in OS X minefield and camino the SVG is not displayed at all in the current nightlies. filed as Bug 366654 


Depending on bug 367031 because the patch there gets the SVG in the button to at least show up again.
Depends on: 367031
No longer depends on: 367031
Summary: SVG used in XUL button does not display correctly → SVG used in XUL button is not active
Depends on: 367031
This is because svg frames seem to trap the mouse event and target it at itself rather than the xul button.

I notice that svg frames have their own implementation of nsFrame::HitTest. Maybe there is some issue there?

Neil - pls read comment #14 - in Fx 2.0 at least, the XUL button shows as pressed in and released when clicking on the SVG, so I don't think it's a matter of the event being trapped, necessarily
Normally, a button will target all events at itself rather than its children. However, when clicking on the svg content, the frame 'traps' the event by targeting it at itself instead. The highlighting and active look are determined by the :hover and :active pseudos (or the native theme equivalent) and will still apply as the button is an ancestor of the active svg content which was targeted.


(In reply to comment #17)
>I notice that svg frames have their own implementation of nsFrame::HitTest.
>Maybe there is some issue there?
At least on trunk, I think roc changed things to use BuildDisplayList.
I put the <svg> inside a <label> to make it work with the reflow branch changes and having done that I had no problem clicking the SVG to activate the button.
#20

Neil,

please could you add an attachment?

it seems the SVG was visible in your test, but when I tried it, it wasn't using ff2.0.0.1 win'98 box, though the attachment as it is displays the SVG in the button. I used:

<label style="font-weight: bold;"
       value="Hello, Welcome to the xFly" >
<svg:svg width="50px" height="50px">
   <svg:rect x="0px" y="0px" width="50px" height="50px" stroke='red' stroke-width="1" fill="green" /> 
</svg:svg></label>
No longer depends on: 367031
Depends on: 294086
The two attached testcases work for me in nightly trunk builds.
Also works for me in 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072705 Minefield/3.0a7pre
marking as fixed, however there remain a number of unresolved issues...

such as: 

  the relation between chrome and SVG. 
why does SVG reach top and bottom but not left and right edges? etc....

  the relation between button value and SVG
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
No longer depends on: 294086
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: