309321 - Firefox should use OS default text editor for View Source instead of internal View Source window

Status: RESOLVED WONTFIX

(Firefox :: Settings UI, defect)

Description

[Andre Sihera]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

When viewing page sources, the User wants to be able to select the editor
of their choice. In fact, the User will want to have *automatically* used
by Firefox the current editor the User has spent effort configuring for
files of type ".txt", etc. E.g: Notepad, Emacs. The User may not want to
be forced to use the internal editor. It doesn't matter if the new editor
happens to be "better" than the one the User prefers and has spent time
configuring or not; to not have the choice is a problem. Moreover, to not
use the default/configured editor, when that is what System Convention is,
is a bigger problem.


Reproducible: Always

Steps to Reproduce:

Comment 1

[Rory Parle]

Dupe of bug 172817?

Comment 2

[Andre Sihera]

Bug 172817 seems have rambled off on some discussion about how the property
should be configured. Somewhere, buried in all the comments, is a fairly plain
request that the platform should use the default editor as configured on the
system. However, everyone is talking as if this was a UNIX-only bug (i.e. set
the EDITOR_... environment variable on UNIX, etc.)

On Windows, there is a File-associations Database that contains the mapping for
every known type of file extension and the application used to open that file.
Opening a command prompt and type "assoc" will give you the logical mappings.
Typing "ftype" will give you the logical-mapping-to-physical-command-line
mappings.

This is not just about letting the User configure it or not. If a database
already exists containing the definition of a system default/user selected
editor to use, then the database should be queried and the editor automatically
deduced on installation.

This is a broken OS integration functionality.

Comment 3

[Ria Klaassen (not reading all bugmail)]

The default editor for .txt files may not be the one I like to use for viewing
source.
The ViewSourceWith extension might be useful.

Comment 4

[Andre Sihera]

The correct functionality that the application could follow is as follows:

1) Make an internal property available for storing the command-line that invokes
the editor the user wants to use (here-on called EditorCommandLine)

2) Provide a binary option that states "I want to use the Firefox internal
editor regardless". If this option is set then setting the internal property as
no effect. If this option is clear then the internal property (which can be
empty) has an effect (here-on called ForceBuiltInEditor)

By default, this option is *unchecked* (i.e. the system default or system-held
user preference is used, followed by the internal property).

3) The sequence of events is outlined in the following pseudo-code:

string function GetEditorCommandLine()
{
    if (ForceBuiltInEditor)
        return [the command-line to built-in editor]

    if (EditorCommandLine is non-empty)
        return [value of EditorCommandLine]

#ifdef WIN32
    //
    // Win32: filetype-database lookup
    //
    query file association database for file type ".txt"
    return [value of invokation command-line for file type ".txt"]

#else
    //
    // UNIX: query EDITOR environment.
    //
    query environment(EDITOR) and build command-line to the editor
    return the built command-line
#endif
}

Note that in both implementations, if you don't use the EDITOR environment
variable (or whatever the de-facto standard is) then it should be possible to
define a value for the "EditorCommandLine" property as:

$MY_EDITOR_VAR -someflag $1 $2 ...

As, when passed to the shell, this would evaluate to a perfectly valid command-
line (providing MY_EDITOR_VAR was defined). This would then work on UNIX systems
*and* on UNIX emulations on Windows where environment variables are in effect
certain 3rd-party shells.

Comment 5

[Jason Barnabe (np)]

So you're basically saying bug 172817, but default it to the external editor and
do some voodoo on how you'll figure out what that editor is?

Comment 6

[Andre Sihera]

(In reply to comment #5)
> So you're basically saying bug 172817, but default it to the external editor and
> do some voodoo on how you'll figure out what that editor is?

The "voodoo", as you put it, is a completely supported API that the Windows SDK
makes available for setting and querying File Associations that has been there
for the last 10 to 12 years. As the Windows version of Firefox is a NATIVE
installation procedure, which part of "why don't we use the APIs that are
available on the target platform instead of doing a half-baked approach and
ending up with a lowest common denomitator of solution across all platforms?"
amounts to "voodoo"?

This functionality is what Windows people EXPECT. They expect that Notepad will
be the default editor IF they have not configured they're own already, and they
expect that they will have the option to change it if they don't like it. Just
like Unix users EXPECT to find "ksh" or "csh" with "vi" on a vanilla
installation and expect to be able to replace "ksh" with "bash" and "vi" with
"vim" or "emacs" or whatever.

Firefox will not be accepted into the world of Windows until it does at MINIMUM
what people expect. After it does the core minumum to everybody's expectation,
the extra bells and whistles will truly make it something to shout about.

Comment 7

[Jason Barnabe (np)]

I'll take that as a yes. Adding a dependancy to bug 172817.

Comment 8

[Mike Connor [:mconnor]]

Let's be upfront about this: Notepad isn't better for viewing page source than
the pretty-printed source viewer that's included.  Doing what's expected is not
always doing what's better.  This is one of those cases.

This is a dupe of a number of wontfixed bugs, but I'm going to leave this for
the moment as a reminder for when we discuss developer configuration.

Comment 9

[BoffinBrain]

Attachment: The Windows XP TweakUI application changes the path to the IE source viewer.

I don't like the idea of checking file associations on installation - that will probably change over time.  I assume in just about all cases, one text editor is all anyone needs.  I'm no code junky, but I think the solution is simple...

The View Source addon to Firefox _is_ good, and should be on by default.  
All that users need is an option (please don't mention the 'bloated' option dialog!) to select the program they want to use by its path, since anyone who wants to use their own editor will know where it is installed.  The default path can be notepad.  Virtually all editors take the file as the first argument, so this would appear to be a pretty easy solution.

Take the screenshot of TweakUI for Windows XP.  This is all you need, plus an option to choose between Firefox source viewer and the custom one.

Comment 10

[Andre Sihera]

(In reply to comment #9)
> I don't like the idea of checking file associations on installation - that...

Are you designing software or yourself or for other people?

Please consider that question very carefully before you go recommending that
people should:

1) Be forced to used tools, by default, that they are not familiar with when all
other applications on their system that are designed properly integrate with the
tools and applications that they like.

2) Instead of allowing the application to just work in an environment that they
have spent possibly years configuring to be just right, forcing them to have to
change some option in some dialog because an application someone else wrote has
decided to ignore completely all the options that the user configured.

3) All of a sudden become technical, after years of being a normal, non-
technical computer users, and magically know that, for example, their favourite
editor called "Wordpad" is actually located in:
"C:\Program Files\Windows NT\Accessories\wordpad.exe".

I strongly recommend everybody to cease judging the merits of features in
terms of their own familiarity with software and computers and start thinking
about real users in real situations who are a lot less knowledgeable and a lot
more inclined to stop using Firefox at the drop of a hat because it does
something they don't like and they don't have the knowledge, nor the inclination
to go into some dialog and change some option they don't understand.

File associations IS the right way to do it and is the platform's UI-integrated
standard method for doing it. The windows installation is a windows-only peice
of software anyway. Where else do you think this feature could possibly be
implemented? You're either developing for the Windows platform or you're not.
Doing a half-baked job isn't going to solve the problem and is going waste a
whole load of time in the process. A double-lose in my opinion.

Comment 11

[BoffinBrain]

(In reply to comment #10)

Yeah, I hear where you're coming from.  I do like the file associations idea - I meant specifically checking only once during installation:

comment #2
> ... and the editor automatically deduced on installation.

That obviously wouldn't work, but checking the association each time view-source is called will work.  This assumes that the user has the correct association set for ALL types of web document e.g. html, htm, css, xml...  otherwise some file types may not be set to open in any program, and the whole idea breaks down.

That's why I suggested that Firefox choose ONE program.  This should make things easier.  For instance, Firefox could view source for any file, using the editor that associates itself with html files or on a similar check.

Anyhow, whichever choice is made, we'll still need an option somewhere to turn this feature on, since many users like the View-Source addon as it is.

I do base these opinions, not just on my own needs, but what I think others are looking for.

Comment 12

[BoffinBrain]

This bug has made no progress in over a year.  Can we have it confirmed please?

Comment 13

[Marco Bonardo [:mak]]

see comment #8 for the reason this is not confirmed yet

Comment 14

[BoffinBrain]

I agree with comment #8 but I propose, as originally suggested, that this should be configurable.  Suggest changing the title of the bug to "Firefox should allow user-specified text editor for View Source"?

Comment 15

[Jason Barnabe (np)]

(In reply to comment #14)
> I agree with comment #8 but I propose, as originally suggested, that this
> should be configurable.  Suggest changing the title of the bug to "Firefox
> should allow user-specified text editor for View Source"?
> 

Firefox already does that.

http://kb.mozillazine.org/View_source.editor.external
http://kb.mozillazine.org/View_source.editor.path

Comment 16

[BoffinBrain]

Thanks very much for that!  Now, is there any chance of putting it in the UI, so that non-Mozilla-programmers will know this feature actually exists?

Comment 17

[Marco Bonardo [:mak]]

imho that feature is not needed by everyone, but only by advanced users, that can easily find the about:config options... so probably this should not go into the UI prefs

Comment 18

[Robert Strong (they/them - no direct email)]

As stated in comment #15 this is already possible and the only thing missing is UI. Changing the component to preferences since the capability is already implemented.

Comment 20

[Andrei Boros]

I vote WONTFIX. 

Firefox's internal source viewer is much better then standard "notepad". 

IMO this bug is more like a statement: let's make firefox behave like MSIE.

Comment 21

[Henri Sivonen (:hsivonen)]

I think this should be WONTFIX. Firefox's own View Source now has error reporting and highlighting features that e.g. notepad, gedit and TextEdit don't have.