Bug 34429 – [Qt] window.alert fails to display HTML tag

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Qt

Steps to Reproduce:
1) Launch QtLauncher.
2) Save the file windowtest.html.
3) Open the file windowtest.html from QtLauncher.
4) Click on the Display Alert button.

Expected Outcome:
-----------------
'<p>string in between <tag></p>' is displayed as an alert without HTML
formatting (<p> is treated like a string).


Actual Outcome:
---------------
'string in between' is displayed as an alert instead. And if
'<script>somescript</script>' is put as a n argument instead, nothing will be
displayed in the alert box.

Mozilla Firefox 3.5.2 displays '<p>string in between <tag></p>'
Apple Safari 4.0.1 displays '<p>string in between <tag></p>'

Created attachment 47843 [details]
windowtest.html for QtLauncher

[Andreas Kling]

Created attachment 47914 [details]
Patch to escape HTML entities in JS alert/prompt boxes

[Andreas Kling]

And (about the testcase): you can't have </script> inside a JS string literal, that stops the parser in its tracks. See for example: http://www.herongyang.com/JavaScript/Browser-Include-Script-Tag-in-String-Literal.html

[Andreas Kling]

Created attachment 47918 [details]
Patch fixed to work with all 3 JS dialogs

We should do the same for all the JS dialog types. :)

[WebKit Commit Bot]

Comment on attachment 47918 [details]
Patch fixed to work with all 3 JS dialogs

Clearing flags on attachment: 47918

Committed r54228: <http://trac.webkit.org/changeset/54228>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Simon Hausmann]

I wonder if the escaping should perhaps be done on the ChromeClientQt side, instead of in the default implementation. That way we can unit test this bug fix and not every application that re-implements these handlers has to do the same Qt::escape trick.

Unless of course there's a compelling reason to forward the tags to the application...