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.
Created attachment 119028 [details] screenshot Look at the screenshot, folding marks are at different lines. Steps to reproduce: - create XHTML file - place cursor somewhere inside <body> and type <div></div> - place cursor in between the <div> and </div> and hit enter several times (2-3) => problem occurs, to fix it just save file and the marks are immediately redrawn to correct positions. Once this is done if you press Enter for the same element the problem does not happen again. To reproduce it you have to create another <div>... I cannot reproduce it in any other file type (html, php, jsp...). This is very similar to issue #201270 but this happens without collapsing/expadning folds. Product Version: NetBeans IDE 7.2 Beta (Build 201205021516) Java: 1.7.0_04; Java HotSpot(TM) Client VM 23.0-b21 System: Linux version 3.0.0-19-generic-pae running on i386; UTF-8; en_US (nb)
reproducible in php web page as well...
Happens, I've seen it myself, but with low probability. Even switching editors fixes the issue, so it does not seem to be folding model bug, but rather folding sidebar or the editor not reporting Y-axis change in editor views properly (or cf sidebar not handling the Y-axis change well).
Created attachment 119075 [details] Log from cf sidebar Attached log shows how the sidebar was updated. The part after === marker occured only after document save. Note fold count & positions - fold boundaries were misreported until save. Vladimir - did you notice this effect just in HTML, in other CSL-based stuff (PHP, JS) or in non-CSL text as well (e.g. Java, XML) ?
Only in XHTML file (I didn't reproduce it even in .html...)
Created attachment 119086 [details] Better log, showing also GSF Fold manager operation According to this log, the GSF Fold Scan initiated after newlines were inserted into the document, still reports the OLD folding information; as if the parsed source was read before the newlines appeared - see the sequence: FINE [org.netbeans.editor.CodeFoldingSideBar]: Doc inserted: </div> FINE [org.netbeans.editor.CodeFoldingSideBar]: Doc inserted: INFO [org.netbeans.modules.parsing.impl.SourceCache]: sourceModified called FINE [org.netbeans.modules.csl.editor.fold.GsfFoldManager]: GSF Fold scan started FINE [org.netbeans.modules.csl.editor.fold.GsfFoldManager]: Scanner reported folds: {tags=[OffsetRange[156,354>, OffsetRange[204,265>, OffsetRange[270,346>, OffsetRange[285,296>, OffsetRange[305,334>], comments=[]} Also note the HTML scanner reported 5 folds, which is not correct; the state before <div> contains 3 folds; the state after </div> contains 4 folds. Note the attached file; it differs from the above 'parsed' state just by being saved. No further modification is done. It may be still possible that HTML parser/scanner is fed an obsolete/inconsistent snapshot from Parsing API. Currently I have no idea how to verify or reject such possibility; please advise.
BTW note: any modification, save, or editor tab switch will fire up a new parser event and the situation is remedied, so I am not sure it's P3. But it IS annoying, especially when you stop typing, want to have an overall look at the source and the error just happens.
Created attachment 119088 [details] Saved file for reference what offsets in the log mean or should mean
I guess it causes also incorrect coloring in xhtml jsf page Check the screenshot, to reproduce: - create new Java Web application with JSF framework - in index.html, inside <h:head> element create (TYPE, not cpoy&paste) <style> - invoke cc after <style> and select & confirm </style> - press enter 2-3 times => bad coloring To fix the coloring, press any key/switch to different editor window/save file and it is "refreshed" and OK Product Version: NetBeans IDE Dev (Build 201205100400) Java: 1.7.0_04; Java HotSpot(TM) Client VM 23.0-b21 System: Linux version 3.0.0-19-generic-pae running on i386; UTF-8; en_US (nb)
Created attachment 119337 [details] screenshot with incorrect coloring
I'll take a look at the issue
the semantic coloring issue as described by Vlada is also reproducible, the cause is likely the same as Svata described. As the folding and semantic coloring are both provided by CSL, and the html code does nothing more that operates on the given parser result, passing back to CSL. I haven't observed similar problems on any of the features depending on parsing.api, resp. the html parsing result, but not on CSL. Looks like some task thread replanning issue there.
OK, it seems the defect is inside Parsing API; here is a sequence of logged document modification and HTML parser result creation. Note the serial number of Snapshots passed to the HTML parser. InsertUpdate: 290:6 = </div> Created HTML parser result: org.netbeans.modules.html.editor.api.gsf.HtmlParserResult@32a703bf for snapshot Snapshot 1927744147: newxhtml24.xhtml( text/html 0-316) InsertUpdate: 290:1 = InsertUpdate: 291:8 = InsertUpdate: 290:1 = InsertUpdate: 291:12 = InsertUpdate: 303:1 = InsertUpdate: 304:12 = Created HTML parser result: org.netbeans.modules.html.editor.api.gsf.HtmlParserResult@124beb36 for snapshot Snapshot 1927744147: newxhtml24.xhtml( text/html 0-316) What is interesting (to me) is that IndexingAwareParserResultTask hooked on text/xhtml gets the CORRECT Snapshot to its run(ParserResult, SchedulerEvent). More precisely, the run() methods receives a XhtmlElLanguage.XhtmlElParser.FakeResult, which has exactly one text/html embedding. That embedding's resultIterator has a correct Snapshot (with accurate and up-to-date contents), but the embedding's ParserResult has an obsolete Snapshot. I am able to reproduce approx 1/3 of time on the supplied source and a scenario. Try to: * open the file * type <div>, wait for the completion </div> to appear * hit Enter approx 3 times (accept suggestion + 2*newline)
*** Bug 222638 has been marked as a duplicate of this bug. ***
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss