Closed
Bug 77390
Opened 23 years ago
Closed 23 years ago
should display <noscript> content if nsScriptSecurityManager::CanExecuteScripts returns false
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: pollmann, Assigned: pollmann)
References
()
Details
(Whiteboard: fix in hand, need approval)
Attachments
(2 files)
5.19 KB,
patch
|
Details | Diff | Splinter Review | |
4.41 KB,
patch
|
Details | Diff | Splinter Review |
We currently display <noscript> content only if the 'javascript.enabled' pref is set to false. We should instead display <noscript> content if the script security manager disables script for any reasone (e.g., nsDocShell::SetAllowJavascript(PR_FALSE)) This will ensure that <noscript> descriptive text is displayed for content whenever scripts are not running. This is a follow-on to bug 77227
Assignee | ||
Comment 1•23 years ago
|
||
Assignee | ||
Comment 2•23 years ago
|
||
The reason I split this check out into a static function and used it in two places is because in HTMLContentSink::ProcessSCRIPTTag() it says: // Don't process scripts that aren't JavaScript and don't process // scripts that are inside iframes, noframe, or noscript tags, // or if the script context has script evaluation disabled: But we would go ahead and try to process scripts even when script was disabled because nsIScriptContext->GetScriptsEnabled is always returning true (which seems bad in and of itself?) Perhaps I should leave the check of nsIScriptContext->GetScriptsEnabled there as well - and if either that or IsScriptEnabled is false, don't process the script tag?
Status: NEW → ASSIGNED
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9.1
Comment 3•23 years ago
|
||
TM to 0.9.2 (as a bug that needs to be done before RTM) per PDT triage.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Assignee | ||
Comment 4•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Whiteboard: fix in hand
Assignee | ||
Comment 5•23 years ago
|
||
Harish, Johnny, can you r=/sr= this patch? Thanks!
Whiteboard: fix in hand → fix in hand, need r/sr/a
Assignee | ||
Comment 6•23 years ago
|
||
Johnny says "sr=jst@netscape.com", thanks!
Whiteboard: fix in hand, need r/sr/a → fix in hand, need r/a
Nit pick: Could you delay JSContext declaration further? ;-) r=harishd.
Assignee | ||
Comment 8•23 years ago
|
||
Thanks - in fact, Johnny suggested the exact same change during super-review, so I have declared it right where it is assigned: + JSContext* cx = (JSContext *) scriptContext->GetNativeContext(); + NS_ENSURE_TRUE(cx, PR_TRUE); Handing to drivers for approval...
Whiteboard: fix in hand, need r/a → fix in hand, need approval
Comment 9•23 years ago
|
||
a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)
Blocks: 83989
Assignee | ||
Comment 10•23 years ago
|
||
Patch checked in. There is no way to directly verify this bug at the present time. As embedding clients begin to have features like disabling javascript in a mail window, and so forth, this should be verifiable.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•