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.
Build: NetBeans IDE Dev (Build 200902231810) VM: Java HotSpot(TM) Client VM, 11.2-b01, Java(TM) SE Runtime Environment, 1.6.0_12-b04 OS: Windows XP, 5.1, x86 User Comments: jdwyah: large rhtml file GUEST: Editing an ERB file trying to insert a link_to tag. GUEST: Editing rhtml file Stacktrace: javax.swing.text.BadLocationException: end=61 > length()=60 at org.netbeans.lib.editor.util.swing.DocumentUtilities.getText(DocumentUtilities.java:333) at org.netbeans.modules.ruby.rhtml.EmbeddedSectionsHighlighting.isWhitespace(EmbeddedSectionsHighlighting.java:147) at org.netbeans.modules.ruby.rhtml.EmbeddedSectionsHighlighting.access$200(EmbeddedSectionsHighlighting.java:77) at org.netbeans.modules.ruby.rhtml.EmbeddedSectionsHighlighting$Highlights.moveNext(EmbeddedSectionsHighlighting.java:216) at org.netbeans.spi.editor.highlighting.support.OffsetsBag.addAllHighlightsImpl(OffsetsBag.java:723) at org.netbeans.spi.editor.highlighting.support.OffsetsBag.addAllHighlights(OffsetsBag.java:184)
Created attachment 77612 [details] stacktrace
This issue has already 10 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=146269
Easily reproducible: 1. in an empty rhtml file type <%, the closing %> will automatically be added, so the line will look like <%|%> 2. press enter and this exception will pop up
local changeset: 4f89b3155bc7
I had to revert http://hg.netbeans.org/jet-main/rev/4f89b3155bc7, because it was causing commit-validation failuers. http://hg.netbeans.org/jet-main/rev/c20cf3c564dd
Integrated into 'main-golden', will be available in build *200903261933* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/4f89b3155bc7 User: Vita Stejskal <vstejskal@netbeans.org> Log: #159502 - allow access to the artificial '\n' at the end of a document
Still reproducible by vstejskal steps.
40 duplicates => P2
Vito, how do you think this should be fixed if not like in 4f89b3155bc7? AFAICT this is not a regression in ruby.rhtml.
I don't know, will have to have a closer look.
Ok, I'm not able to think of anything better that the original fix. IMO it's a correct fix and AFAICT the test that was affected by it has been changed in the way that it's now passing even with the original fix. So, I pushed the original fix. Just for the record the affected test is org.netbeans.test.xml.schema.AcceptanceTestCase.checkSourceCRC(). http://hg.netbeans.org/jet-main/rev/2b54697873bc
Integrated into 'main-golden', will be available in build *200905140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/2b54697873bc User: Vita Stejskal <vstejskal@netbeans.org> Log: #159502: another attempt to fix document's CharSequence; org.netbeans.test.xml.schema.AcceptanceTestCase.checkSourceCRC() now ignores EOL characters and so should not fail again due to this change
Fix results in cnd unit test falure see IZ#165147
*** Issue 164183 has been marked as a duplicate of this issue. ***
I have strong objections about the way the issue has been fixed. It looks harmless because changes so small. But it can affect many places in sources. Try find usage of the AbstractCharSequence.length(). I've managed to resolve that the reason of 22 JUnit tests in XDM model are failed because of this fix. The problem happens because of the XMLLexer gets a length increased by 1 (see my attachment with the stack trace) and eventually the redundant /n appears in the model. I'm pretty sure that the bug #168113 caused by this fix. And I have seen the same behavior in different XML editors. Another problem is the change of the length meaning. So it can be considered as an API modification. I think it had to pass the API review.
Created attachment 91591 [details] Stack trace where the length works a wrong way
Please reopen only in case you know how to fix the original problems that are described in the comment inside the method. If the correct solution is to change line highlighting API please reopen only after that API has been changed so we can use it.
It's strange requirement. Issue still exists. And it should be open till will be fixed.
The final committed fix (with confessed extra newline at doc.getLength()+1 in the CharSequence returned by DocumentUtilities.getText(doc)) was the best fix that we were able to find and we are not going to change it unless someone else will provide us with a better fix. Vita S. and I have discussed the pros and cons of this fix carefully since we were aware of most of the consequences and agreed on it. The original problem is of course the fact that Swing's AbstractDocument allows things like doc.getText(0, doc.getLength() + 1); doc.createPosition(doc.getLength() + 1); lastParagraphElement.getEndOffset() == doc.getLength() + 1 and we may only find a best response to this weirdness in our CharSequence view of the document. If you need our help with fixing problems caused by this fix please file a separate issue. Thanks.