Closed Bug 88123 Opened 24 years ago Closed 23 years ago

w/ browser running, doing 'edit' from windows explorer opens empty page

Categories

(Core Graveyard :: Cmd-line Features, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.8

People

(Reporter: shrir, Assigned: law)

References

Details

(Keywords: platform-parity, Whiteboard: [QAHP] EDITORBASE)

Attachments

(1 file)

as the summary states...if I have a browser instance running and I use windows explorer to edit a html doc from my HD ( right click->Edit)...then what opens up in editor is the 'HTML Test Page' and not the actual document that I clicked on.. If no browser instance is running, then right clicking on a html file on my HD...launches the browser and opens up the html doc in composer
what are you talking about?
I see that same behavior running on win2k. When I right mouse click using the context menu and open an html file on my hard disk, the test page is displayed in the composer.
oh, I get it, you are right clicking on the desktop icon -- I see that too, that's quite odd to get the test page
*** Bug 88313 has been marked as a duplicate of this bug. ***
handing over to command line engineer, this must be hard-coded somewhere
Assignee: beppe → vishy
Component: Editor → XP Apps: Cmd-line Features
QA Contact: sujay → sairuh
*** Bug 92492 has been marked as a duplicate of this bug. ***
can we get a target milestone for this bug?
Keywords: nsbeta1
nav triage team; Marking p3, mozilla0.9.4, reassigning to pchen, adding nsbeta1+
Assignee: vishy → pchen
Keywords: nsbeta1nsbeta1+
Priority: -- → P3
Target Milestone: --- → mozilla0.9.4
This belongs to editor. See bug 93737.
Assignee: pchen → beppe
Component: XP Apps: Cmd-line Features → Editor
Keywords: nsbeta1+
QA Contact: sairuh → sujay
Target Milestone: mozilla0.9.4 → ---
I'm going to dup 93737 to this older bug, but wanted to copy some info from that bug here: When using Composer to open files from anywhere outside of Mozilla (i.e. from win explorer), Editor just opens some Ender test page. Luckily that's not too embarrassing! The real fix will be to let other apps pass in arguments, but for now (just to remove loading the test page), the fix is to change value to about:blank or nothing: http://lxr.mozilla.org/seamonkey/source/editor/ui/composer/content/editor.xul#10 5 looks like pav did that part of the code -- cc'ing him
*** Bug 93737 has been marked as a duplicate of this bug. ***
assigning this to brade to get some traction on it
Assignee: beppe → brade
It's Windows only, so brade isn't the appropriate person
Assignee: brade → cmanske
Keywords: pp
This works correctly in my Netscape 6.1 installation: There is a Windows registry entry to associate an application to "open" and "edit" HTML and HTM file types: In the HKEY_CLASSES_ROOT section, we register our file association in the key = "MozillaHTML->shell->open->command" as N:\NETSCAPE\NEAC18~1\NETSCP6.EXE -url "%1" (the path to your installed netscape program) and for key = "MozillaHTML->shell->edit->command" as N:\NETSCAPE\NEAC18~1\NETSCP6.EXE -edit "%1" If I right click on an HTML file in Windows file explorer, there is a context menu option "edit", which loads the file into Composer correctly. So is the issue that we aren't doing this in the mozilla build? Maybe this registry stuff is only happening in the Netscape Commercial build?
I can't vouch for the mozilla builds, but I do see this on Commercial. On Win2K, in "Internet Options, there are three options for "HTML Editor:" "Netscape" "Netscape Navigator" "Notepad" Using the first instance ("Netscape") should do what I'm asking it to do, in fact that's what should happen when I choose to use N6 as my default internet app, but setting the HTML Editor to "Netscape" then gets me to the Ender test page when I use the context menu|edit command. Using the second instance - "Netscape Navigator" opens 4.x Composer. So, we're not registering ourselves as a "MAPI-like" option as the HTML editor on Win2K. Can't vouch for other platforms.
I see this in commercial, it happens when I go to Edit in MOZILLA (yes, it's a commercial build) in IE's File menu. And it makes sense that it's happening; look at the code snippet I provided, that beppe cited.
Blake--why does it make sense that the editor not be opening the file you want to edit?
Well, I don't know Editor that well -- how are external applications supposed to pass in the url they want to load? It makes to me from a limited code perspective because we load the value of args: http://lxr.mozilla.org/seamonkey/source/editor/ui/composer/content/editor.js#214 and args defaults to the test page: http://lxr.mozilla.org/seamonkey/source/editor/ui/composer/content/editor.xul#105 and I don't see how an outside application could pass an argument into window.arguments to override that.
As I said in my description of the Windows' registry entry, the filename is passed in as the "%1" in the "edit" registry entry. We should definitely change the default "args" value to be "about:blank", though, and not the test page. Can someone who has installed using the mozilla or NS commercial build please show what they are seeing for the "MozillaHTML->shell->edit->command" entry in their Windows registry?
Status: NEW → ASSIGNED
Charlie, I have the commercial 0806 trunk on my NT box: The 'MozillaHTML->shell->edit->command' on my wndows registry shows the following: "C:\TESTS\0806TR~1\NETSCP6.EXE-url "%1'"'
I checked in Blake's proposed fix (sr=kin) This bug should now be "why don't we open the file instead of an empty window"
Summary: with browser instance running, doing 'edit' from windows explorer opens up 'Ender HTML Test Page' → w/ browser running, doing 'edit' from windows explorer opens empty page
I see this: "C:\PROGRA~1\NETSCAPE\NETSCA~1\NETSCP6.EXE -edit "%1""
moving to 1.0
Target Milestone: --- → mozilla1.0
*** Bug 96462 has been marked as a duplicate of this bug. ***
*** Bug 97812 has been marked as a duplicate of this bug. ***
we're getting lot of DUPS...marking QAHP
Keywords: nsbeta1
Whiteboard: [QAHP]
*** Bug 98501 has been marked as a duplicate of this bug. ***
*** Bug 91967 has been marked as a duplicate of this bug. ***
*** Bug 99359 has been marked as a duplicate of this bug. ***
spam composer change
Component: Editor: Core → Editor: Composer
This is a module startup or DDE issue. Discussion with Bill Law reveals that there are a few annoying problems with launching apps on Windows platforms, using DDE to launch windows, differences in different Windows versions, etc.
Assignee: cmanske → law
Status: ASSIGNED → NEW
Component: Editor: Composer → XP Apps: Cmd-line Features
QA Contact: sujay → sairuh
Whiteboard: [QAHP] → [QAHP] EDITORBASE
After the request for publishing functionality, this is the most referenced bug for Composer in the netscape feedback newsgroups. Is there any way to get this fixed before mozilla 1.0?
I'll look into this at least. Not sure about fixing it yet.
Target Milestone: mozilla1.0 → mozilla0.9.7
Blocks: 104166
cc: curt....Curt, you mentioned you were experiencing this problem also...
Marking nsbeta1+ per syd. Need to fix for composer usability.
Keywords: nsbeta1+
*** Bug 109351 has been marked as a duplicate of this bug. ***
Resetting target milestone for all "window integration" bugs to mozilla0.9.8. I'm working on performance and won't get to that till next milestone.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** Bug 113422 has been marked as a duplicate of this bug. ***
*** Bug 114657 has been marked as a duplicate of this bug. ***
The problem is that we weren't doing the hard command line handling when requests came in from secondary processes. I've fixed that by reusing the code already in nsAppRunner.cpp that handles initial startup. Notes for reviewers: nsCommandLineService.cpp: 1. Need to make copy of argv array because HandleRequest has no means of freeing it otherwise. This was actually a lurking bug that was never hit because nobody else was calling GetArgv on the cmdlineservice it built. Likewise, we free the copy in the dtor. nsAppRunner.cpp: 1. DoCommandLines needs to tell HandleRequest whether it opened a window or not so a default Nav window can be opened if one wasn't (like Ensure1Window does in nsAppRunner.cpp itself). So a PRBool result was added to the LaunchApp functions, the pref enumerator "closure" struct, and to DoCommandLines. Almost every change in this file was to add support for returning that state indicator. 2. I removed the assertion in HandleArbitraryStartup. Previously, the only caller to DoCommandLines always ensured "heedStartupPrefs" was true if there were no command line args. But that's not the case from HandleRequest (in cases where there are no command lines but windows are already open). Rather than avoid calling DoCommandLines in this case, I removed the assertion. The code subsequent to the assertion is fine regardless (it keys off argc anyway) and this will permit us the flexibility to move the Ensure1Window-like logic into DoCommandLine at some point. nsNativeAppSupport.h: 1. Added extern declaration for DoCommandLines. nsNativeAppSupportWin.cpp: 1. I changed the code for TURBO_NAVIGATOR to ask use "-browser" (otherwise, choosing Navigator used the startup prefs). 2. In the WM_LBUTTONDBLCLICK code, I removed the check for open windows (it moved to HandleRequest. Note that this means double-clicking always opens at least one window, per bug 101025. 3. Removed code that called GetStartupURL. 4. Inserted (after handling "-kill") code that: a. Ensures a profile (moved from further down; this needs to happen before trying to open a window). b. Calculates whether we need to pay attention to startup prefs. Commented sufficiently, I hope. c. Calls DoCommandLines and returns if it opens a window. 5. Removes GetStartupURL() which is no longer used.
*** Bug 117430 has been marked as a duplicate of this bug. ***
Comment on attachment 63412 [details] [diff] [review] Fix for this bug and some others (101025 and 99321, maybe more) r=sgehani
Attachment #63412 - Flags: review+
*** Bug 119998 has been marked as a duplicate of this bug. ***
*** Bug 99814 has been marked as a duplicate of this bug. ***
Comment on attachment 63412 [details] [diff] [review] Fix for this bug and some others (101025 and 99321, maybe more) sr=blake Looks good. There are some 2 space/4 space indentation inconsistencies that should be fixed.
Attachment #63412 - Flags: superreview+
fixed
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verified fixed using 2002.01.29.10 comm verif bits on win2k --after making sure that n6.x was set to handle html docs [checked it on in the Adv > System pref panel].
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
QA Contact: bugzilla → cmd-line
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: