If any other occurrences of the selected text are off the page when the replacement begins, they will not show any highlighting: yellow or blue.

reproducible

*** Bug 204091 has been marked as a duplicate of this bug. ***

Current behavior - not selecting next occurrence after replace - is intended behavior. It also doesn't jump in editor view, because some user want to have a time to check replace. 

However, I believe it's interested suggestion, therefore I change this to enhancement and I will create a checkbox or a button to say that you want replace and then find.

*** Bug 152128 has been marked as a duplicate of this bug. ***

I disagree with the current behavior. If the next match is within view (no scrolling needed) then the editor should highlight it. There is no good reason not to. Currently (dev build 201110050601) nothing gets highlighted. There is no indication where the caret is. The user has no way of knowing where he/she is...

Thanks for chiming in. I think there far more weight should be given to existing editors and what they do... which is not what NB currently does.

Note that the editor does in fact select the next element for replacement, but it does not highlight it.  Since the point of the selection is to give visual confirmation to the user, that confirmation is missing.

(In reply to comment #6)
> I disagree with the current behavior. If the next match is within view (no
> scrolling needed) then the editor should highlight it. There is no good reason
> not to. Currently (dev build 201110050601) nothing gets highlighted. There is
> no indication where the caret is. The user has no way of knowing where he/she
> is...

No there is a good reason not to highlight next match, and that is if I highlight next match, after closing replacebar the caret is after highlighted text and not after replaced text, where IMHO should be.

(In reply to comment #7)
> Thanks for chiming in. I think there far more weight should be given to
> existing editors and what they do... which is not what NB currently does.
There is in fact a respectable precedent for my suggestion to have 3 separate buttons Find, Replace+Find and Replace. Replace+Find does exactly what it says (combine the actions of the two others); it will likely be used most often (meriting its own button, currently called just Replace), but pure Replace is still available to be able to do post-editing around a replaced string without jumping through hoops (the dialog must be non-modal). The selection after closing the dialog is determined by which button was clicked last.

(Oh, and I would still like a Find Previous button in there, as for the plain Find dialog, because checking a box to change direction is too much trouble. And no, that doesn't mean there should be a "Replace+Find Previous" button.)

> No there is a good reason not to highlight next match, and that is if I
> highlight next match, after closing replacebar the caret is after highlighted
> text and not after replaced text, where IMHO should be.

Perhaps you are also responsible for the behavior of the search. That is,
 - type ^f to start a search
 - type in a known string below the current search window. The view changes as you type.
 - Now either (a) hit escape, or (b) hit return and then hit escape

If you choose (a) your view warps back to where you were before the search. If you hit return, *nothing* changes on the display, but when you then hit escape, you remain where the search left you.

This behavior and the one being discussed in this bug are in the category of surprising the user. Part of the surprise comes from a user model established well before netbeans existed. Consider a survey of other editors that have a "replace" operation.
 - Thunderbird email editor: "replace" replaces the current selection and does not move to the next; "Replace and Find" replaces the current selection and selects the next occurence.
 - Microsoft word: "replace" replaces the current selection and selects the next occurence. There is no button to replace and not change the selection.
 - Eclipse: "replace" replaces the current selection and does not move to the next; "Replace/Find" replaces the current selection and selects the next occurence.
 - Netbeans 7.0.1 on windows (interestingly enough):  "replace" replaces the current selection and selects the next occurence. There is no button to replace and not change the selection.

You have to conclude that (a) linux netbeans 7.1 changes the replace model not only from 7.0.1 but from other influential editors, and (b) the linux netbeans 7.1 "replace" button is really a "Find next and replace" rather than a "Replace and find next".

You are too late to change the world. Please do what other editors do.

> There is in fact a respectable precedent for my suggestion to have 3 separate
> buttons Find, Replace+Find and Replace.

I think this is an excellent idea. Just note that the current UI visually and logically implements "Find+Replace", not "Replace+Find".

Ok, it is regression -> Bug #204820 is fixed today.