Open Bug 1330675 Opened 4 years ago Updated 3 years ago

Consider adding support for style API for disabled SVG nodes

Categories

(Core :: DOM: Security, defect, P3)

52 Branch
x86_64
Linux
defect

Tracking

()

People

(Reporter: jkt, Unassigned)

References

Details

(Whiteboard: [domsecurity-backlog1][tor])

When I load invision with SVG disabled I get the following error:
  TypeError: e.style is undefined

STR
1. go to about:config
2. set svg.disabled to be true
3. visit https://mozilla.invisionapp.com/share/WF9INQMBM

By changing the node to a generic XML element the page can't interact with SVG in the same manner as it could before.
The element when embedded within a HTML node could use a HTML element instead of SVG or firefox could add in dummy apis that don't actually work.
Hey Arthur,

Do you know if tor handles this correctly when the user enabled scripts on the page?
Do you have any thoughts on which approach should be used to solve this?

Thanks
Flags: needinfo?(arthuredelstein)
Whiteboard: [domsecurity-backlog1]
(In reply to Jonathan Kingston [:jkt] from comment #1)

> Do you know if tor handles this correctly when the user enabled scripts on
> the page?

Hi Jonathan,

I just tried it and found the same error in Tor Browser (using our old SVG disabling patch). 

> Do you have any thoughts on which approach should be used to solve this?

I'm inclined to think it should remain broken, because we have disabled SVG. But I'm open to other ideas.
Flags: needinfo?(arthuredelstein)
Should we WONTFIX this? What would be the advantage of providing dummy APIs? The page wouldn't get a script error, that's correct, but how advantageous is that?
Flags: needinfo?(jkt)
The advantage is that it doesn't throw. In the example site I showed it would make the page work. So it likely would vastly reduce JS breakage.

Feel free to find me to talk about it.
Flags: needinfo?(jkt)
Whiteboard: [domsecurity-backlog1] → [domsecurity-backlog1][tor]
You need to log in before you can comment on or make changes to this bug.