Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 179786 - Navigator "Please Wait" when undocked and closed.
Navigator "Please Wait" when undocked and closed.
Product: editor
Classification: Unclassified
Component: Parsing & Indexing
PC Windows XP
: P3 (vote)
: 7.0
Assigned To: Tomas Zezula
Depends on:
  Show dependency treegraph
Reported: 2010-01-22 06:53 UTC by xBellox
Modified: 2010-11-02 14:43 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT

Plase wait message (60.91 KB, image/jpeg)
2010-01-22 06:53 UTC, xBellox

Note You need to log in before you can comment on or make changes to this bug.
Description xBellox 2010-01-22 06:53:46 UTC
Created attachment 93488 [details]
Plase wait message

The message "Please Wait" remains forever in Navigator (with undocked window) in the follow cases:

1) Starting with navigator window docked
 1.1) While editing a file, undock the Navigator window
 1.2) Close Navigator
 1.3) Edit/Focus the file agian
 1.4) Press "ctrl+7" to reopen the navigator
    (When you select another file it works again)

2) Starting with navigator window undocked
 2.1) Select one file
 2.2) Close the Navigator
 2.3) Select another file
 2.4) Press "ctrl+7" to reopen the navigator
Comment 1 Filip Zamboj 2010-01-25 07:34:00 UTC
it's not about docked navigator window only. It doesn't refresh if opened when other file is focused. 

as the reporter wrote: 
1. open file 
2. check if the navigator shows something relevant and not please wait. 
3. close navigator 
4. open navigator while you have focus on editor. 

you see please wait until you focus or close/open file. 

if you open navigator using window -> navigating -> navigator it woks well again after you focus editor. 

Product Version: NetBeans IDE Dev (Build null)
Java: 1.6.0_16; Java HotSpot(TM) 64-Bit Server VM 14.2-b01
Comment 2 Filip Zamboj 2010-01-25 07:36:55 UTC
reassigning to editor -> csl - does it belong to you guys?
Comment 3 David Strupl 2010-09-23 13:46:42 UTC
Even after my last commit this seems still to cause problems. Trying to debug ...
Comment 4 David Strupl 2010-09-30 13:35:51 UTC

After the last change in CSL this needs to be fixed in Parsing API. Passing the report to the parsing api category.

toRemove should better handle when someone is re-adding the same task right after its removal.

Steps to reproduce the problem: try to watch the navigator when switching between .html and .js files in the projects explorer.
Comment 5 Tomas Zezula 2010-10-01 07:31:20 UTC
Seems that task is not readded after fast sequence of add remove from multiple threads.
Comment 6 Tomas Zezula 2010-10-01 09:03:59 UTC
The reason is a dupliction of requests in toRemove queue. The problem is that the Hanz' schedulers have different semantic from the java schedulers. Hanz schedulers are run once and do not reschedule while the java schedulers do rescheduling. This causes that the request is neither among requests nor in finishedRequests. So removing it causes deferring the remove (the request is added into the toRemove queue). Fix requires non trivial change in TP :-(
Comment 7 Tomas Zezula 2010-10-01 12:01:51 UTC
fixed jet-main b5ba4cc6b65f
Comment 8 pgebauer 2010-11-01 15:17:54 UTC
The committed fix introduced regression. For regression description, please see
Comment 9 Tomas Zezula 2010-11-01 17:14:22 UTC
The parsing api commit is guarded by unit tests. If the problem is in the csl part report on the proper component or add an unit test.
Comment 10 Tomas Zezula 2010-11-01 17:42:49 UTC
To pgebauer: Please do not blindly create (reopen) issues on parsing api, do it if either unit tests fail or you are sure it belongs to it. I've reverted the parsing api patch and the PHP navigator has the same problem as reported in issue #191289. Certainly nothing in common with parsing api.
Comment 11 pgebauer 2010-11-02 14:23:00 UTC
I would never reopen this issue without a try with reverted fix. I have reverted the following changeset which has changed csl.api and it seems to be part of this issue.  The issue BZ#191289 has disappeared after the reversion. Unfortunately this is not true with my todays build. It seems that the root of BZ#191289 is somewhere else.
Comment 12 Tomas Zezula 2010-11-02 14:33:59 UTC
In that case it's only problem of modules.
The issues on CSL do not belong to the parsing api they belong to CSL.
Feel free to reopen but assign to CSL.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo