Bug 34429 - [Qt] window.alert fails to display HTML tag
Summary: [Qt] window.alert fails to display HTML tag
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Qt (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords: Qt
Depends on:
Blocks:
 
Reported: 2010-02-01 07:40 PST by sangeetha.sugavanam
Modified: 2010-02-10 07:20 PST (History)
4 users (show)

See Also:


Attachments
windowtest.html for QtLauncher (504 bytes, text/html)
2010-02-01 07:45 PST, sangeetha.sugavanam
no flags Details
Patch to escape HTML entities in JS alert/prompt boxes (1.80 KB, patch)
2010-02-02 02:01 PST, Andreas Kling
kenneth: review+
kenneth: commit-queue+
Details | Formatted Diff | Diff
Patch fixed to work with all 3 JS dialogs (2.38 KB, patch)
2010-02-02 03:37 PST, Andreas Kling
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description sangeetha.sugavanam 2010-02-01 07:40:05 PST
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>'
Comment 1 sangeetha.sugavanam 2010-02-01 07:45:06 PST
Created attachment 47843 [details]
windowtest.html for QtLauncher
Comment 2 Andreas Kling 2010-02-02 02:01:09 PST
Created attachment 47914 [details]
Patch to escape HTML entities in JS alert/prompt boxes
Comment 3 Andreas Kling 2010-02-02 02:03:36 PST
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
Comment 4 Andreas Kling 2010-02-02 03:37:08 PST
Created attachment 47918 [details]
Patch fixed to work with all 3 JS dialogs

We should do the same for all the JS dialog types. :)
Comment 5 WebKit Commit Bot 2010-02-02 05:00:03 PST
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>
Comment 6 WebKit Commit Bot 2010-02-02 05:00:11 PST
All reviewed patches have been landed.  Closing bug.
Comment 7 Simon Hausmann 2010-02-10 07:20:38 PST
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...