crash on some SVG pages when svg.in-content.enabled=false

Kathy and I found a web page that consistently causes a NULL pointer dereference during page load in TB 4.5 when svg.in-content.enabled is set to false (e.g., when the security slider is set to the highest position).

We are working on a fix; the problem is related to the fact that elements with the SVG XML namespace are created as regular XML elements when svg.in-content.enabled=false.

added TorBrowserTeam201504R component::applications/tor browser owner::tbb-team priority::very high resolution::fixed status::closed tbb-4.5-alpha type::defect labels

Trac:
Cc: brade to brade, mikeperry
Priority: major to critical
Keywords: N/A deleted, tbb-4.5-alpha added

Here is a fix: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug15794-01&id=3006aa548cefa2f9d0968c978786dcefa9309119

Trac:
Keywords: N/A deleted, TorBrowserTeam201504R added
Status: new to needs_review

Ok, this looks good as a fix. I merged it and Georg and I started a rebuild.

However, this issue makes me a bit more nervous about the namespace-based solution in general. Can we be reasonably sure that there are no other potential issues with this namespace change either allowing scripts to execute when they shouldn't, or allowing strange codepaths?

If not, we may want to create a pile of test cases for this type of stuff when we do the ff38-esr rebase and patch submission to Mozilla.

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

Replying to mikeperry:

Ok, this looks good as a fix. I merged it and Georg and I started a rebuild.

However, this issue makes me a bit more nervous about the namespace-based solution in general. Can we be reasonably sure that there are no other potential issues with this namespace change either allowing scripts to execute when they shouldn't, or allowing strange codepaths?

Thanks for reviewing the fix. I am reasonably confident that scripts will not execute, etc. but the codepaths are complicated enough that it is difficult to be 100% certain. This specific problem occurred because Kathy and I did not consider the fact that the HTML parser would do special things with some elements such as and <script> when enclosed within <svg> blocks. In fact, it does not seem to be doing too much, e.g., just recording line numbers (presumably so that it can report the correct one in the inspector tool). And the crash occurred because when SVG is disabled the elements are not created the same way (which is good, because that prevents special behavior when the pages are rendered but bad because we had not looked at this codepath).</p> <blockquote data-sourcepos="8:1-8:139"> <p data-sourcepos="8:3-8:139">If not, we may want to create a pile of test cases for this type of stuff when we do the ff38-esr rebase and patch submission to Mozilla.</p> </blockquote> <p data-sourcepos="10:1-10:185">I agree and I opened #15802 (moved) to track adding test cases. I will also take another look at <script> right now and test to ensure that JS is not executed when svg.in-content.enabled=false</p>

Replying to mcs:

I will also take another look at

closed

mentioned in issue #15795 (moved)

mentioned in issue #15802 (moved)

mentioned in issue #16397 (moved)

moved to tpo/applications/tor-browser#15794 (closed)

mentioned in issue tpo/applications/tor-browser#15795 (closed)

mentioned in issue tpo/applications/tor-browser#15802 (moved)

mentioned in issue tpo/applications/tor-browser-bundle-testsuite#40048