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.
I'm using NetBean's MDI style on the new RedHat 7.3 with j2sdk-1.4.0-fcs. I have made a new web application with NetBean's wizard. When I load the web.xml file in the editor, it's not colored by the syntax-highlighting and parts of it are hidden: - Sun Public License Notice - The part inside between <session-config> </session-config> - All index.* and </welcome-file> lines. All the other lines are visible. When I move the cursor over the hidden lines the lines become visible but vanish again when I scroll the contents of the window. When I move an other top level window over NetBean's toplevel window the text also appears but vanishes again, when I raise NetBean's window again. This might be an X11 problem, but NetBeans and the XML file are the only ones were this happens. Editing JSPs or ASCII files works perfectly. If anyone is interested I can mail him/her a screenshot.
This could be a bug in the lexical scanning support of the editor. However we need the reproducible case to fix it. Did it happen just once (if you reopen the file the problem disappears) or repeatedly? If the problem is reproducible could you please attach the problematic file to this bug? Thanks.
No, the problem did not disappear when reopening the file or restarting NetBeans. But it's an transient bug. I can not reproduce it everytime. It happened with the unmodified default web.xml generated by the "new web app" wizard. In the meantime I had also problems with own written JSP files.
this belongs to ui -and to Dusan.
I tried to reproduce this bug but without success. Boris could you send your screenshot or problematic file please ?
Created attachment 6607 [details] Screenshot showing the missing lines in web.xml (JPEG-Quality: 30%)
Created attachment 6608 [details] Matching web.xml used for the screenshot
I've created a new WebApp and opened the default web.xml for making this screenshot for you. You can see in the screenshot what lines are not displayed. If I place the text cursor at the beginning of one of these missing lines and start moving it to the right using the cursor keys, the characters of the invisible appear one after the other. Each character appears as soon as the cursor is exactly before it. This means if I can read <session-ti on the screen the cursor is between the t and the i. When the cursor enters the next line the previous line again disappears. I could not make a screenshot of this situation, because as soon as I clicked in the Gimp window for making the screenshot, the Gimp window gets activated and the partly displayed line again disappears! I had the same problem with a switch/case construction yesterday. I use XFree86-4.2.0-8 with no Gfx problems in other applications.
Set target milestone to TBD
*** Issue 26293 has been marked as a duplicate of this issue. ***
Bug occured also in a scriptlet (JSP) using NetBeans 3.4
I have these problems still in NetBeans 3.4, even with JDK 1.4.1. Currently it happens in a JavaBean source. Very annoying.
*** Issue 28030 has been marked as a duplicate of this issue. ***
I have the same problem, but didn't find this issue at first so I filed a new (#28472). For me it only happens in jdk 1.4(.1)! When I go back to jdk 1.3 it works fine. For me the problem have occurred in HTML and java files. It is more common for HTML files though. In some cases it have actually helped to close and reopen the file, but in other cases that doesn't work. I'm suspecting the colorization code as responsible for this. This never happens for file types that are not colorized!
*** Issue 28472 has been marked as a duplicate of this issue. ***
Created attachment 8408 [details] Screen shot showing missing code
Created attachment 8409 [details] Screen shot showing correct code after restarting NetBeans
*** Issue 28071 has been marked as a duplicate of this issue. ***
*** Issue 26855 has been marked as a duplicate of this issue. ***
I've integrated the new document content into the editor. The lexer states are now stored at the beginings of the lines so the updating of the lexical states is now fixed and will no longer depend on the distribution of the syntax marks in the document. Unfortunately it seems that the bug is still present as the issue 30981 occured with the fresh build that was using the new content.
*** Issue 30981 has been marked as a duplicate of this issue. ***
At this time only P1s and P2s are allowed to be integrated into newly created branch "release35". Changing target milestone to 4.0
*** Issue 31603 has been marked as a duplicate of this issue. ***
*** Issue 32244 has been marked as a duplicate of this issue. ***
With 3.5 RC1 a have this problem too. I'm using a Debian Woody system with j2sdk1.3.1_7 from Sun. Working on a jsp with some directives and a scriptlet the scriptlet disapears if the closing %> is not in the window. If the window is big enough the scriptlet is shown but a taglib-directive not. Also the displayed row and column of the cursor behave strange. Only hitting the Cursor-Down-Key is says (the scriptlet is always displayed): 1:1 2:1 ... 6:1 7:51 // this is a line with a taglib directive which is not displayed 8:1 9:3 // the cursor stays at 8:1 the scriptlet beginns 10:43 // the cursor stays at 8:1 11:72 // the cursor stays at 8:1 12:1 // the cursor stays at 8:1 13:72 ... 24:1 // end of scriptlet, the cursor is at 24:1 Moving up now tha blinking cursor stays at 24:1 till it appears at 8:1. Clicking somewhere in those lines with the mouse gives the same values. The displayed value for the column is always the position behind the last character in the line. If I hit CURSOR-RIGHT or CURSOR-LEFT the display in the statusbar counts right. So left of 13:72 is 13:71 and right of 13:72 is 14:1. This doesn't happen with NB 3.4.1
Adding a comment from other user (same symptom): ------------------------------------------------------ I'm working on Studio 5 a lot with jsp's and Tag libs. Sometimes the Editor gets confused and is not showing all the text, but some Characters are painted in white. ------------------------------------------------------
Changing the summary (adding other file types as the problem appeared in JSP as well as Java and HTML).
Today I tried the 3.5RC1(zip download) with Windows 2000 and had the same effect as with my Debian system. So I tried to open the file in the default project without adding the classes to it and there was no problem with the cursor or with vanishing lines.
We are seeing this problem also. However, we see it both in a NetBeans-based component and another component (JTextArea) that just makes minimal use of NetBeans syntax highlighting (and it sometimes shows up in the regions that are not highlighted by NetBeans). Therefore it may be a more general Swing problem. Are there any known workarounds?
Originally I thought that there is a problem in the code that manages SyntaxMarks so I have rewritten the code so that SyntaxMarks are no longer used and the lexer state is stored in LineElement of each line. Unfortunately the problem still occurs. In my spare time I'm working on a rewrite of the whole painting system of the editor but I cannot promise any concrete date when that will be finished.
*** Issue 34109 has been marked as a duplicate of this issue. ***
*** Issue 34263 has been marked as a duplicate of this issue. ***
*** Issue 34363 has been marked as a duplicate of this issue. ***
I don't agree with P3 because this is highly visible problem for users. I hope that samples attached to #34363 can help to reproduce it.
Created attachment 10685 [details] a jsp that freaks out the editor
*** Issue 33838 has been marked as a duplicate of this issue. ***
I've just seen it on Linux with JDK 1.4.1_02 and NB build 200306160100. I've tried to open Java source file. It opened white page without any chracters with cursor in the middle of the page. There was line numbers but there wasn't scroll bars. I had opened a few files but empty was only one.
*** Issue 33829 has been marked as a duplicate of this issue. ***
*** Issue 33957 has been marked as a duplicate of this issue. ***
*** Issue 34387 has been marked as a duplicate of this issue. ***
Another user encountered the problem and reported it on nbuser alias: http://www.netbeans.org/servlets/ReadMsg?msgId=531842&listName=nbusers
*** Issue 34534 has been marked as a duplicate of this issue. ***
*** Issue 34111 has been marked as a duplicate of this issue. ***
*** Issue 34718 has been marked as a duplicate of this issue. ***
How to reproduce the problem: ----------------------------- 1. run last dev build (7.7.2003) 2. via explorer create a new file in examples folder - examples.Test.java 3. place cursor to line 20 (last line) and press enter (create a new line). Now, two empty lines are the last lines. 4. Add a breakpoint to the line 20 and 21 5. save document 6. modify the Test.java externaly - Remove last two lines and save 7. return back to NB. Document should reload and throw exception "The document Test could not be loaded"... (see bellow) (Sometimes the document is not reloaded after external change, perhaps another bug. In this case, return back to external editor type space and backspace, just modify the document and save. After that operation NB editor should reload) 8. after this exception that is already mentioned in issue #33040 there are drawing problems as reported in this issue. The excerpt of exception: Annotation: The document Test could not be loaded. java.lang.IndexOutOfBoundsException: Invalid line index=19 >= lineCount=19 at org.netbeans.editor.LineRootElement.getElement(LineRootElement.java:54) at org.openide.text.NbDocument.findLineOffset(NbDocument.java:124) at org.openide.text.DocumentLine.updatePositionRef(DocumentLine.java:428)
Please fix this in 3.5.1. JSP editing is currently a real pain with NetBeans. I am using 3.5 on W2K, WXP and Solaris 2.8 with JDK1.4.1. No wonder, that Eclipse is getting market share quickly... Yes, I am totally annoyed. Georg
I have the same problem with Windows 2000 so I set OS to "All". For me it happens when I select lines containing taglib directives in a jsp file: they become blank and cannot be selected. Very annoying. It also happens when I select lines in jsp comments: the coloring changes.
This bug should be set to P1 because it is often *impossible to edit* a jsp page. It's hard to have an IDE which is less useful than Notepad :-( Also I wonder what determines the priority of bugs: are votes taken into consideration? What about opening date?
*** Issue 35267 has been marked as a duplicate of this issue. ***
The easy way of getting rid of those duplicate entries is simply to fix the bug ;-)
Those dupes should count as votes. I've never seen so many dupes on an issue to which I've subscribed.
Having just found this bug which I dup'ed I wish to second the Java 1.4.1 notion, that's where I'm at under 3.5 also. Plan to test with another Java level (1.4.0.somebuild) tomorrow against 3.5.1 on Solaris 9.
The thing, that troubles me most about this issue is, that I never hear of any progress or work being done on this blocker. So when will NetBeans 3.5 be useable for serious web application development? Any ideas? What about the planned HotFix site?
Everybody who finds this bug very annoying should vote for this issue.
Let me give an update of the status regarding this issue: - we are able to partly reproduce the problem if we make a reload of a document. However we are still unable to simulate the problem if the reload is not done. - as the issue occurs even with plain text the original thought that the issue is connected to a problem in Syntax classes of the particular syntax coloring are unlikely (or at least they are not the only cause of the problem). - recently we have identified one of the possible causes of the problem - if the EditorUI.repaintBlock() is entered with a wrong offset (either startPos or endPos) the resultintg BadLocationException is consumed silently and the repaint() that would normally be done is skipped. - there is still a problem regarding missing Document.render() in most of the org.openide.text functionality - issue #33040. The problem is likely connected to this one. The editor implementation is not the culprit here even though the resulting exception occurs in the editor's code. There is an ongoing work to review the thread model of the o.o.text tracked under issue #33165. That would allow us to fix the issue #33040 too. Although I've already refactored PositionRef, DocumentLine and NbDocument classes to use Document.render() later I've found that there is a serious threading problem when instantiating a java template and overriding methods. Issue #33165 contains the details. Both #23569 and #33165 are currently our highest priorities however we are unable to predict when we will have a complete fix. At least we will provide several partial fixes that will eliminate most serious occurrences of the two issues.
Thanks for the detailed update!
*** Issue 35216 has been marked as a duplicate of this issue. ***
The problem of BadLocationException silent consuming in EditorUI.repaintBlock() should be fixed in [maintrunk] Please, try to run tomorrow dev build using "-J-Dnetbeans.debug.exceptions=true". If you can still reproduce the issue, please attach an ide.log. Thanks. /cvs/editor/libsrc/org/netbeans/editor/EditorUI.java,v <-- EditorUI.java new revision: 1.46; previous revision: 1.45 /cvs/editor/libsrc/org/netbeans/editor/GuardedDocument.java,v <-- GuardedDocument.java new revision: 1.15; previous revision: 1.14 /cvs/editor/libsrc/org/netbeans/editor/LeafView.java,v <-- LeafView.java new revision: 1.41; previous revision: 1.40
*** Issue 35355 has been marked as a duplicate of this issue. ***
Created attachment 11329 [details] ide.log which shows everything is not corrected, yet
*** Issue 35781 has been marked as a duplicate of this issue. ***
A bit more anectodal information: 1) happens more often if I immediately scroll a file after loading it; DOES NOT happen if I load a file AND WAIT approximately 5 seconds before scrolling. 2) only happens in JSPs for me dev-build 200309260100, jdk 1.4.2_01, rh8 poo@hiney.org
Maybe unimportant: 1) Only happens in JSP for me 2) Is not nearly as bad "vanilla JSP tags" but as soon as I implement use of f.e. jstl core+fmt tags editing becomes almost impossible 3) Waiting after opening file before doing anything seems to help
Just to say that I've been seeing this problem on and off since 3.4, and for me it's only occured for Java classes and occasionally jsp. It doesn't happen all the time, but usually when it does usually closing down and restarting NB solves the problem. However at this moment in time, it's occuring repeatedly. Platform SuSE 8.1, JDK 1.4.1, NetBeans 3.5.1, 512Mb ram
*** Issue 35236 has been marked as a duplicate of this issue. ***
We were able to reproduce on the computer of one of the QA guys. We've added some debugging right before calling Graphics.drawChars(): /cvs/editor/libsrc/org/netbeans/editor/DrawGraphics.java,v <-- DrawGraphics.java new revision: 1.15; previous revision: 1.14 and it confirmed that we are sending the right text to the Graphics.drawChars() with the right color set and correct clip is set. So it seems that it is a problem on JDK side or something on our side that causes JDK to behave incorrectly but we don't know what it could be. The symptoms seem exactly like in http://developer.java.sun.com/developer/bugParade/bugs/4242596.html in the BugParade but we are still unable to reproduce reliably by a set of concrete steps.
Yes I have seen that BugParade entry before. The strange thing is that I've only seen it occur with NetBeans, not in any other apps, and strangely not in one of my own apps that's based on the NetBeans Platform. Also it's not occuring as often as it was. When I placed the previous comment it was occuring almost every time NetBeans was started, but now it occurs once every few days (ie: It occured once today but the last time was a week ago). The only major change to the setup is that I'm running JDK1.4.2_02 now not 1.4.1 - which to me also points to the JDK. I'm rebuilding this machine in a week's time, so we'll see if it reoccurs then. That may rule out OS related causes.
*** Issue 35542 has been marked as a duplicate of this issue. ***
Please, please set this to P1 and fix it once and for all. This has plagued me now for more than 14 month! It can't take years to fix a bug that can be reproduced reliably on Solaris with NB35 and the latest hotfix installed, when opening JSPs. But I guess, even the Netbeans guys are using windows only for testing ;-) Regards Georg
We are working on this bug in S1S5. We had reproduced bug with JSP and find a remedy for that. The problem with JSP files is in the HTML parser support. But we can't reproduce this bug with other file types mentioned in bug reports. So I will appreciate if someone attach java or html examples with broken behaviour of editor.
In case JSP files it happens because HTML parser is pending.
Created attachment 12663 [details] this patch fixes this bug in case JSP files
Sorry, this patch is incorrect
Created attachment 12674 [details] new patch
Created attachment 12676 [details] corrected new patch
i test as described in http://www.netbeans.org/issues/show_bug.cgi? id=34263
My apologies that I did not catch to evaluate the recent input to this bug sooner. I've looked to the editor part for the last attached patch (I would ask Petr Pisl to look at the rest JSP-related stuff). I mostly agree with the changes (if all the tests that we have pass) except the following change: *** LineRootElement.java 24 Apr 2003 16:54:16 -0000 1.4.2.1 --- LineRootElement.java 26 Dec 2003 12:01:34 -0000 *************** *** 230,236 **** text.count -= preScan; // load state into syntax scanner - will scan from mark up to reqPos ! syntax.load(stateInfo, text.array, text.offset, intraLineLength, false, reqPos); --- should become --- syntax.load(stateInfo, text.array, text.offset, intraLineLength, forceLastBuffer, reqPos); If we would do this change then in case the forceLastBuffer would be true the token would be forcibly ended at reqPos and a new token would start at reqPos which is IMHO undesirable and would change the semantics. The forceLastBuffer was meant to affect the situation at reqPos+reqLen not at reqPos. Java prepareSyntax() example: reqPos reqPos+reqLen | | ----------------------------------- int i = abcd;\n i += 3;\n ----------------------------------- With current state the "abcd" would be returned after prepareSyntax(). I would expect that "cd" would be returned after the proposed change. Was there any direct motivation for this change? Have you been testing any concrete example of failure that this change has fixed? BTW there was another bug fixed related to jsp lexing - it's issue 39005.
Another note - the situation when a file that was opened before IDE shutdown and it is completely blank after IDE restart is not related to this issue - it's a separate problem related to view hierarchy introduced by code folding and we are just working on the fix for that problem.
- The root cause of problems with JSP editor was fixed - problem with web.xml that happened in Nb332 is not reproducible anymore - probably fixed by several other fixes - repainting problem with java sources is not reproducible (might be a problem with combination of OS, JDK and some HW) Feel free to reopen the bug if you see the same symptoms in NB36 dev build.
Verified in dev 200402241900. Editor shows all lines.