I deleted URL and gave all info here instead:

Description
-----------
Currently Navigator reacts to lookup changes, node destroy events and top component closing asynchronously, in different
ways, with different reaction delay. This may lead to unpredictable results and random wrong updates of navigator area.

Solution is to rewrite all listener reactions to delegate to one task, which would manage all update requests and
possibly coalesce them if needed. Asynchronous update delay will be kept to improve performance when update requests are
coming too quickly.

Dependencies, Risks & Fallbacks
-------------------------------
All Navigator API clients could be possibly affected, so behavior should be preserved by test. Test should trigger
updates from various triggers and check for proper navigator infrastructure reactions.

Time Estimation: 3 man days 

> Asynchronous update delay will be kept to improve performance when update requests are
> coming too quickly.
Does this mean that when the navigator is opened, it will idly wait for some hundreds of milliseconds before updating
first? Is this the reason why Navigator always displays "Please wait..." message for some time after opening a Java
file? If so, I suggest the following simple algorithm to improve the user experience:

State:
1. long delay = x milliseconds
2. long last_upd_time = -1
3. Timer timer = create inactive timer
4. List waiting_queue = []

Update event handling:
1. add the event to waiting_queue
2. is timer scheduled?
2.1. yes: return
2.2. no: last_update_time <= current_time - delay?
2.2.1. yes: startUpdate()
2.2.2. no: schedule the timer to run in (delay - curr_time + last_upd_time) ms

When the timer is fired:
1. start_update()

startUpdate():
1. last_upd_time = curr_time
2. perform_update(waiting_queue)

moving opened issues from TM <= 6.1 to TM=Dev