This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 226744 - Error triggered for <script> inside of <textarea>
Summary: Error triggered for <script> inside of <textarea>
Status: NEW
Alias: None
Product: web
Classification: Unclassified
Component: HTML Editor (show other bugs)
Version: 7.3
Hardware: PC Linux
: P4 normal (vote)
Assignee: Milutin Kristofic
Depends on:
Reported: 2013-02-26 21:55 UTC by bfrohs
Modified: 2014-10-06 13:25 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description bfrohs 2013-02-26 21:55:44 UTC
Product Version = NetBeans IDE 7.3 (Build 201302132200)
Operating System = Linux version 3.5.0-25-generic running on i386
Java; VM; Vendor = 1.6.0_27
Runtime = OpenJDK Client VM 20.0-b12

For the following HTML snippet, an error is reported in the gutter (over line number) and text is underlined red for the line with the <script> tag. However, that line is, as far as HTML is concerned, plain text. Ergo, it should not report an error.

<!doctype html>
<script> function(){} </script>
Comment 1 Vladimir Riha 2013-05-23 08:59:29 UTC
reproducible in trunk
Comment 2 Marek Fukala 2013-07-12 12:52:52 UTC
Is fn w/o name valid? In any case this is javascript editor issue as the same error appears in pure js file with "function (){} " content.
Comment 3 Marek Fukala 2013-07-12 12:54:52 UTC
(In reply to comment #2)
> Is fn w/o name valid? In any case this is javascript editor issue as the same
> error appears in pure js file with "function (){} " content.
pls disregard :-)
Comment 4 Marek Fukala 2013-07-12 13:02:33 UTC
You are right, textarea element's content type is text so the content should not be treated as html content and hence colored and parsed by javascript editor.

However the javascript embedding creation inside the script section is now based on lexical analysis only so there's no info about the parent element. Creation of the js embedding based on parser analysis is not convenient - we've already tried before few years and returned back to lexical only analysis. In theory I could keep the lexical based js embedding creation and remove the embedding from such areas based on parser result, but it seems to be to be quite complicated solution for IMHO marginal issue. I'm downgrading this to P4 if you do not mind.