Jardo just in case you'd have a time could you please look at it? Otherwise I'll take a look.
Vladimir don't you know when the problem started?

Mila, I think if revert 
http://hg.netbeans.org/jet-main/rev/108b9b214479
then the second event will have non null pane as it was before.

At least I know for sure that a day before http://hg.netbeans.org/jet-main/rev/108b9b214479
events were correct

Hi Vladimir,
 IMO the code in CsmUtilities is rather threading sensitive and so it's likely that it may fail (although I still don't see why my EditorRegistry patch causes failure like this since in fact it only does an extra putClientProperty() at pane opening time).
 Anyway I suggest to replace the code in CsmUtilities.openAtElement() with the attached patch which appears to work reliably and should be more threading stable.

Created attachment 110872 [details]
Patch for CsmUtilities

Hi Mila,
May be I´m wrong with changeset, but If you have a look at your test 
CloneableEditorCreationFinishedTest.testEditorPaneFinished
then you can see that
support.getRef ().getAnyComponent ();
previously was CloneableEditor, but now it is TopComponent
and I think recent pane is not set yet at time of sending PROP_OPENED_PANES

Btw, if you have a look at our implementation of PROP_OPENED_PANES listener then it is the same as you have in your test testEditorPaneFinished where on the second event ed.isEditorPaneReady() have to be TRUE while now it behaves like it is false causing findRecentEditorPane to return null
Btw, previously CloneableOpenSupport.allEditors was a reference to CloneableEditors now, it´s a reference to MultiViewCloneableTopComponent instead of MultiViewCloneableEditor which I would expect

Mila, Unfortunately I can not apply proposed patch, because it changes async open to sync openDocument.
But more important is that PROP_OPENED_PANES event currently become incorrect, because client does not have access to editor panes at all.
If client will try to use getOpenPanes method from change listener => he will get problem described in issue #199820

Jarda, can you help with the current changes CloneableEditor->MultiViewCloneableTopComponent (instead of MultiViewCloneableEditor)?

(In reply to comment #6)
> support.getRef ().getAnyComponent ();
> previously was CloneableEditor, but now it is TopComponent
MultiViewCloneableTopComponent (instead of MultiViewCloneableEditor?)

Hi Vladimir, I have made a test build with my
http://hg.netbeans.org/jet-main/rev/108b9b214479
rolled back and it has no influence on the problem.

Since this is likely about changes in multi-view reassigning to platform/WS.

Hi Mila,
Probably I was wrong with exact changeset which caused the problem, but at day when I was fixing issue #199820 (2011-09-09 10:07) events were correct and same as in 7.0.1 code base

I'm sorry, but this regression breaks a lot of our tests, so it is no go for Beta. 
What I can help with - I will use bisect to find problematic commit. Then I expect your help in fixing introduced regression.

What I've got so far:
#hg bisect -g
The first bad revision is:
changeset:   201592:e85bbfccf799
parent:      201590:7edef4591f69
parent:      201591:b31edd9ddcb9
user:        Jesse Glick <jglick@netbeans.org>
date:        Fri Sep 09 13:47:56 2011 -0400
summary:     merge backout

Not all ancestors of this changeset have been checked.
To check the other ancestors, start from the common ancestor, 5906c9488e61.

updating to parent 1
hg up -r 7edef4591f69
=> IDE works

updating to parent 2
hg up -r b31edd9ddcb9
=> IDE works

hg up -r e85bbfccf799
=> broken IDE

I am not involved with this code at all. I merely backed out jtulach's 5906c9488e61 as a convenience since he was not at work.

Workaround exists. Return back to the original editor and click on the element once again. Then the caret will be possition correctly. Making P2.

Jarda, as I said - it breaks all QA hyperlink tests. And we consider it as Beta stopper.

I have tried proposed patch.

Shift from async EditorCookie.open (using event to track when pane was opened) to sync EditorCookie.openDocument is be problem of proposed patch.
As result we don't have hyperlinks into any file which is opened with UserQuestionException => impossible to jump into big files. impossible to jump into non utf-8 files.

hack to workaround problem
http://hg.netbeans.org/cnd-main/rev/33a70aed4c1c

Transplanted into release71_beta:
33a70aed4c1c transplanted to e3893e193f15

So, what is the status of this issue ? Is it fixed ?

(In reply to comment #21)
> So, what is the status of this issue ? 
Regression in platform
> Is it fixed ?
No, but I was pushed to add hack on our side with promise to have fix in Platform in FCS

ergonomics#bb3c22be8a00

> (In reply to comment #21)
> > So, what is the status of this issue ? 
> Regression in platform

Do you mean regression against 7.0.x version? I am sure there is no regression. The MultiViewCloneableEditor class was not even present in 7.0.x version!

In 7.0.x cnd was not using core.multiview at all. During 7.1 you changed your code to use core.multiview. Should there be subtle changes in the behavior, please attribute them to your "switch".

(In reply to comment #23)
> ergonomics#bb3c22be8a00
> 
> > (In reply to comment #21)
> > > So, what is the status of this issue ? 
> > Regression in platform
> 
> Do you mean regression against 7.0.x version? 
I meant regression against 7.0.1 and regression against trunk 
in both cases on the second fire editor pane was ready and non-null. 
Currently it was regressed to always have null.

hg up -r e85bbfccf799
=> broken IDE

updating to parent 1
hg up -r 7edef4591f69
=> IDE works

updating to parent 2
hg up -r b31edd9ddcb9
=> IDE works

Yarda, if you can write test same as CloneableEditorCreationFinishedTest.testEditorPaneFinished

but with used multi-view it would allow us to prevent such regression in future

Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/33a70aed4c1c
User: Vladimir Voskresensky <vv159170@netbeans.org>
Log: workaround for #202242  -  C++ support have lost hyperlink navigation to the exact position and only file is opened

(In reply to comment #24)
> > Do you mean regression against 7.0.x version? 
> I meant regression against 7.0.1 

None of the following change sets comes from 7.0.1: e85bbfccf799, 7edef4591f69, b31edd9ddcb9. This is not regression against 7.0.x.

Test is nice idea: 133dd50e8c25

(In reply to comment #27)
> (In reply to comment #24)
> > > Do you mean regression against 7.0.x version? 
> > I meant regression against 7.0.1 
> 
> None of the following change sets comes from 7.0.1: e85bbfccf799, 7edef4591f69,
> b31edd9ddcb9. This is not regression against 7.0.x.
Or, sorry, now I see. CloneableEditorCreationFinishedTest.testEditorPaneFinished
is used as safe guard that there is no regression against 7.0.x

> 
> Test is nice idea: 133dd50e8c25
Thanks!
Vladimir.

fix http://hg.netbeans.org/cnd-main/rev/bb3c22be8a00
re-introduces issue #201823

After Mila's workaround in C++ code this is at most P2, if not P3.

> fix http://hg.netbeans.org/cnd-main/rev/bb3c22be8a00
> re-introduces issue #201823

applies only to trunk, not to Beta (where the workaround fixed this issue without the side-effect of reintroducing #201823)

ergonomics#e8647c17eecc

Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/133dd50e8c25
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: Per Vladimir's request using the CloneableEditorCreationFinishedTest to test the multiview editor impl for #202242. Works now, Fails on release71_beta_base.