64129 - If file already open in Composer, browser's Open location in new composer window does not find it

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Simon Fraser [no longer active]]

Normally in Composer, opening a file which is already open for editing just 
brings the relevant window to the front, to avoid opening the file twice.

However, this does not work if, when the file is already open in Composer, you 
use the 'Open location dialog' in the browser window (and pick open in new 
composer window). We need to go through the logic to look for an open window with 
that file in this case also.

Comment 1

[Charles Manske]

Attachment: XPFE fix for the bug

Comment 2

[Simon Fraser [no longer active]]

sr=sfraser

Comment 3

[Charles Manske]

All non-editor windows that want to create an editor with a particular url should
now use "editPage()" method in utilityOverlay.js. It will search for
Opening an editor via File | Edit Page, File | Open Location, and "Edit Link" on
the context menu now use editPage().

Comment 4

[Blake Ross]

Reopening, this broke Edit Page and Edit Link in Composer in navigator.

Comment 5

[Blake Ross]

JavaScript error:
chrome://communicator/content/utilityOverlay.js line 441: launchWindow has no pr
operties

Maybe you need to update the calls from nsContextMenu.js and 
navigatorOverlay.xul?  Although you have that launchWindow check.

Comment 6

[Charles Manske]

This seems to be an unrelated problem in
nsEditorShell.cpp::CheckOpenWindowForURLMatch(), which changed recently.
It's chocking when one of the editors hasn't saved to file yet.
Sorry, I realize my testing always used existing files, given the nature of the
bug, that made sense!
It makes better sense to open a new bug for this.

Comment 7

[Charles Manske]

Note that problem found here is now bug 65610

Comment 8

[Blake Ross]

Hmm...really? I can't imagine this not being a problem with the fix, given the 
launchWindow JS error...

Comment 9

[sujay]

verified in 1/30 build.