Closed Bug 145021 Opened 22 years ago Closed 14 years ago

Make source viewer an optionally installed component

Categories

(Core Graveyard :: View Source, enhancement)

Product:
Core Graveyard
Component:
View Source
Platform:
x86
Linux
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: vanbalen, Unassigned)

References

Details

(Whiteboard: [Goat-p1]) 

I'm branching this from the discussion going on in bug 8589 (Make view source
open in text/plain helper app), since I think it merits a separate bug.

I think it's a good idea to, at least, make the source viewer an optional
component when installing Mozilla. Here's, AFAIK, the original proposal:

------- Additional Comment #54 From Ian 'Hixie' Hickson 2002-04-26 15:04 -------

I think we should dump our internal view source and use external editors for the
view source and view selection source commands, working as follows:

   Windows
   -------
   View Source on non-local files should save the file to a temporary place and 
   launch the editor appropriate for the file's MIME type (e.g. if you are
   viewing a text/html file it should launch the program associated with the 
   Edit command of text/html files, for image/png it should similarly launch
   the default Edit command of image/png files). If there is no Edit command
   then for text/* MIME types it should use text/plain's Edit command, and 
   failing that it should use the MIME type's Open command, and failing _that_
   it should use text/plain's Open command, and in the worst case it should
   just launch notepad.exe.

   Linux and Mac
   -------------
   Similar, using the equivalent on these platforms. Linux would fall back to
   $SOURCE_EDITOR and $EDITOR.

View Selection Source should trim the file before doing this (although if you
could get it to pass some LISP code to Emacs that just selects the selection
that would be even better of course).
IMHO, the best way to approach this would be to first implement an option to
have an extarnal viewer (e.g. bug 8589) and then make the internal one an
optional module (that can be ignored by those who are happy always using the
external viewer).
Depends on: ExternalViewSource
Yes, that makes good sense. First make the Mozilla Source Viewer one of our
distinct components, then make it the default source viewer in the shell for
text/html, text/xml, etc when Mozilla is installed, so that by default View
Source will end up launching our own source viewer, but a simple change to the
shell's configuration will change that to be whatever other application is required.

I like it.
No longer blocks: 115903
No longer depends on: ExternalViewSource
This is an invalid bug, and I will mark it so unless you can tell me why not to
dupe it on 8589 in the next few hours.
This bug is about making Mozilla's source viewer a separate component from the
borwser which can be excluded from a Mozilla installation.

Bug 8589, contrary to what's suggested by the million off-topic comments in it,
is about allowing users to set other apps (like emacs, vi or notepad) as their
default source viewer and has little to do with Mozilla's internal source viewer.


-> hixie, goat p1
Assignee: doron → ian
Whiteboard: [Goat p1]
Well, once we live in that world, why not merge the source viewer into Composer
and have "View Source" open up a Composer app in a shiny syntax-highlighted
source editing mode?

IOW, once "View Source" is implemented to delegate to a helper app, and once
Composer is as viable a candidate as any to be the helper app that gets used, do
we even need a specialized source viewer anymore?
Whiteboard: [Goat p1]
That would be a valid way of doing it IMHO, yeah.
Isn't Composer pretty heavyweight compared to the internal viewer?  Embeddors 
might not like that.
As I understand it, the code that could be called "Editor" that doesn't fall
into the category of things that will eventually be (or already are) required
for a fully functional embeddable Gecko are pretty minimal. I could be wrong of
course.
>IOW, once "View Source" is implemented to delegate to a helper app, and once
>Composer is as viable a candidate as any to be the helper app that gets used, do
>we even need a specialized source viewer anymore?

embedding anyone? Composer is not part of embedding, viewsource is.  And
removing the 5 files for the UI is really going to make a huge difference for
us, I'm sure.  Gigantic.

And what about the casual user who sometimes views source?  He doesn't want to
edit the page or anything, just view it.  And he doesn't know about some pref
panel where he can set another viewer?

I still say this is a dupe of 8589. Once that is fixed, everyone will be happy
and this bug can go into invalid heaven.

> Because we are a web browser, not a source viewer. Source viewing should be left
> to applications that are good at viewing source, just like we let other
> applications handle the rendering of movies, word documents, etc.

We are much more than a web browser. This is a web application development
platform, and removing View Source because "better" applications are available
on other computers is a bad direction.

1) The time it takes to load up another application is slower than View Source.
Sometimes, people might want to just peek at the source. They won't want to wait
for an application to open.
2) View source might be familiar to people and it is something they can depend
on being on multiple operating systems. What are windows users going to use? Any
reasonable text editor capable of showing line numbers, coloring source, etc
doesn't come with the system. Notepad and Wordpad aren't good enough for most
people.  Are you going to go through the work to find a reasonable text editor
for every system we port to? For instance, there is a bug for adding line
numbers (bug 15364) to view source. Notepad doesn't have line numbers. 
3) Composer mangles pages and takes a while to load. That's why we can't merge
view source into composer.
4) There are talks on other bugs of making View Source able to view original AND
active source. Constantly loading a new application every time you want to view
active source would be inefficient as compared to a menu option to switch
between the two modes. (Bug 63892) It could also expand <link>ed to files.
5) Many people are fond of view source. It is lightweight and is also used for
embedding. There would be no advantage of removing this code from the tree. If
there are 100+ bugs, I imagine a good majority aren't extremely necessary to fix
and are just feature requests that can be fixed by more casual volunteers.
6) Adding the ability to load the source in another application doesn't mean
that you can't have the Mozilla View Source still available as another menu option.

I recommend we mark this bug WONTFIX and go back to the normal discussion on the
other bug of allowing you to choose your view source application.
btw:

> View Source on non-local files should save the file to a temporary place and 
> launch the editor appropriate for the file's MIME type (e.g. if you are
> viewing a text/html file it should launch the program associated with the 
> Edit command of text/html files

Composer? Yuck! It mangles files. People want to view the _actual_ source

>, for image/png it should similarly launch
> the default Edit command of image/png files). If there is no Edit command
> then for text/* MIME types it should use text/plain's Edit command, and 
> failing that it should use the MIME type's Open command, and failing _that_
> it should use text/plain's Open command, and in the worst case it should
> just launch notepad.exe.

notepad.exe is really a nasty choice. Even wordpad would be better. Yet, wordpad
nor notepad are pretty poor choices and don't show line numbers.

Until there is a replacement (maybe from mozdev.org) we can ship with Mozilla
that is lightweight (loads quickly), shows syntax coloring, line numbers,
doesn't mangle pages, and also is consistently available on every platform that
mozilla ships on, leaving view source is the best choice. It seems to me that
view source is close to fitting this.

Bug 145325 I created to edit a page without mangling it.
> We are much more than a web browser. This is a web application development
> platform, and removing View Source because "better" applications are available
> on other computers is a bad direction.

I don't have a problem with Mozilla providing a way to view source (or do
anything else, for that matter), I just don't want it to come with my browser
whether I want it or not (like grits with your lunch).

> 1) The time it takes to load up another application is slower than View Source.
> Sometimes, people might want to just peek at the source. They won't want to wait
> for an application to open.

And those of us who _do_ want to use another application to view source must
then take a performance hit when we start the browser while the internal source
viewer loads? If we're able to exclude the source viewer from an installation
(like I suggest in this bug), then those who like the source viewer can install
it and use it and the rest of us can not install it and not use it... and
everyone's happy, right?

> 6) Adding the ability to load the source in another application doesn't mean
> that you can't have the Mozilla View Source still available as another menu
option.

I agree (though I would like the option of excluding it from my Mozilla
installation) and should have made my view more explicit in the description of
this bug. Although I think the title "Make Mozilla source viewer a separate
application from Mozilla browser" is pretty clear as to my intention.

Maybe I should change the title of this bug to "Allow users to exclude internal
mozilla source viewer from installation"?
Dave: It should definitely be changed to something. The term "application" is
vague in that it doesn't refer to anything specific at the implementation level.

If "make the source viewer an optional component" is what you meant, then say
that. That is a very different problem from moving the source viewer to another
process (something that is suggested by current summary, albeit not the only
conclusion one might draw from it).

Done. How's that? :-)
Summary: Make Mozilla source viewer a separate application from Mozilla browser → Make source viewer an optional component in mozilla install process (like mail/news and psm)
>And those of us who _do_ want to use another application to view source must
>then take a performance hit when we start the browser while the internal source
>viewer loads? If we're able to exclude the source viewer from an installation
>(like I suggest in this bug), then those who like the source viewer can install
>it and use it and the rest of us can not install it and not use it... and
>everyone's happy, right?

You won't gain much, if it all anything.  Lets make the browser optional too, I
like to use opera sometimes but would want to keep mailnews.
Oh, and I hate that throbber, it slows us down.  Some poeple don't like
tabbrowser, make it a component too!  And scrollbars, my 21'' monitor runs a
high enough resolution that I don't need them.
Summary: Make source viewer an optional component in mozilla install process (like mail/news and psm) → Make source viewer, throbber, statusbar, tabbrowser,scrollbars ptional components in mozilla install process (like mail/news and psm)
Doron: Sarcasm is neither appropriate nor effective. If you think this bug
should be resolved INVALID, by all means make a rational and *civil* argument
for that case.
Summary: Make source viewer, throbber, statusbar, tabbrowser,scrollbars ptional components in mozilla install process (like mail/news and psm) → Make source viewer an optionally installed component
I'm following your argument - why should an embedder have tabbrowsing? It just
slows us down.  We should make it optional. Either you go al the way or none of
the way.
My main argument wasn't by any means a performance increase during startup. I
could really care less since I leave the browser running pretty much all the
time. However, I'm sure that for others it probably is... have you ever started
mozilla on a Pentium? Or a PII, for that matter (no, this isn't a rant about
startup performance so, please, nobody go there).

If you think tabbed browsing, etc should be optional, by all means file a
separate bug for it. Once it's optional, I'll install it and you won't. That's
the way it started out in the first place with multizilla and I sure wasn't the
person who filed a bug to build tabbed browsing into mozilla.
I still see no reason why viewsource should be a component? Use if it you want,
or don't. It doesn't cost any startup at all.  The throbber slows us down, as
does the status bar.
This bug would be affected by bug 145640 - which is about making a way to
activate view-source still available when there is a helper applications selected. 

If you choose not to install viewsource, it should either let you know you
haven't installed it and give you an opportunity to grab the .xpi or whatever,
or it should not show the original view-source menu option.
Why make view source a component? There're reasons in favor and against.

Probably the biggest reason not to make it a component is: if it ain't broke,
don't fix it. Which, by itself, is a good reason.

However, I also see some compelling reasons why it might be a good idea to make
it a component:

- The performance gains, however small they may end up being, will still be
there and every little bit counts.
- I'm sure the executable takes up some space on disk, however little that may
be. Not installing it would free up that much space.... and every little bit
counts for some people.
- The sooner distict components are modularized, in my experience. the better.
While the above two reasons are minor now, they may become major at some point
in the future, at which point it might be a lot harder to fix the problem.
- And, finally, if view source is an integrated part of the browser, you might
reason, why not tabbed browsing/calendar/scheduler/emacs/internet explorer/media
player/kitchen sink? Making the browser truly _only_ a browser will give people
less excuse to keep adding things that "come with it" automatically.

I'm sure other people can come up with other reasons for and against this bug,
but the above is what I can think of right off the top of my head.
>- The performance gains, however small they may end up being, will still be
>there and every little bit counts.

The throbber is more of a perf hog, remove that first, then I will remove
viewsource.  Actually, the componentizing will cost more - blake has found that
moving the overlay content into the actual xul saves us around 26% of startup time. 

>- I'm sure the executable takes up some space on disk, however little that may
>be. Not installing it would free up that much space.... and every little bit
>counts for some people.

the throbber image takes up more space I am afraid to say.

>- The sooner distict components are modularized, in my experience. the better.
>While the above two reasons are minor now, they may become major at some point
>in the future, at which point it might be a lot harder to fix the problem.
>- And, finally, if view source is an integrated part of the browser, you might
>reason, why not tabbed browsing/calendar/scheduler/emacs/internet explorer/media
>player/kitchen sink? Making the browser truly _only_ a browser will give people
>less excuse to keep adding things that "come with it" automatically.

tabbed browsing is part of the browser already.  get your facts straight.
(and in fact so is calendar, if you build with it enabled as I do)

The only valid reason I see to split the source viewer from the browser is the 
same reason that I have for wanting to split Composer, MailNews, Calendar, 
Address Book, Download Manager, Chatzilla, etc:

   They aren't the same application.

View Source used to be just a simple window that showed the source, but in 
recent months it has gained a wealth of features (and there are dozens of open 
RFEs that are apparently not headed for the WONTFIX block) which have made it 
as useful as some other dedicated source viewing applications.

That is why IMHO it should be split.

Once split, it should integrate with the Browser application in the same way as 
MailNews integrates with it -- through open, published Mozilla-specific 
integration APIs and through the official APIs of the GUI shell. For instance, 
clicking on a news:// link should fire up MailNews using the registered 
Windows' URI scheme handler hooks, and picking View Source should launch the 
source viewer associated with the appropriate file type. (The Mozilla-specific 
hooks would be for things like letting Chatzilla display online status for 
users in Mail, without having to run in the same process. View Source would 
probably use such hooks to implement View Selection Source.)

The internal details of this -- such as Mozilla apps sharing a Gecko instance --
are just that, internal details. The user should not be aware of them.
I agree with Hixie on this and I also feel that, if possible, Composer, View
Source, etc should be separate processes as to crash independently. I also feel,
as mentioned in bug 127122, that quicklaunch (in windows) should also be a
separate process so its not lost when Mozilla crashes and can pull it back up
afterwards, much like the windows 2000 and xp shell does with explorer.exe.

Another good reason for modularizing Mozilla is so that people can take the bare
minimum of the application in order to write their own XUL and XPFE based
cross-platform application.


>I agree with Hixie on this and I also feel that, if possible, Composer, View
>Source, etc should be separate processes as to crash independently. I also feel,
>as mentioned in bug 127122, that quicklaunch (in windows) should also be a
>separate process so its not lost when Mozilla crashes and can pull it back up
>afterwards, much like the windows 2000 and xp shell does with explorer.exe.

so suddenly this is about adding threading?

>Another good reason for modularizing Mozilla is so that people can take the bare
>minimum of the application in order to write their own XUL and XPFE based
>cross-platform application.

they still can, just remove the files and change some make files.
Sorry, I got a little off topic. All I was saying is that I would I'd like to
see all components (such as view source if it became a component) independent
processes as not to crash each other.

The question is: Is source viewer - in its present or future form - enough to
warrant a new component?

In its present form, I would argue, "No" since, afaik, it doesn't affect the
memory footprint or loading speed of mozilla significantly (as Doron mentioned).

If its broken off, though - it could much more easily be extended to be a more
generic text viewer (or even editor) for all of Mozilla (for instance MailNews
Mail Source Viewer) and even other projects based off Mozilla. So, in that
respect, I do see merit for breaking it off.
Severity: normal → enhancement
my goat still wants this.
Whiteboard: [Goat-p1]
(Speaking as an enthusiastic user and evangelist, not a Moz developer)

Don't tell me what I should use to view source. I'd like to decide myself,
thanks all the same.

Having a specialist 'source viewer' integrated into the browser only adds to
code bloat for the 98% of users who never use it (OK, 99.99% of browser users;
50% of current Moz users). Even if the moz viewer were more functional than
notepad (ie about as useful as a carrot for this purpose) it's unlikely to be
the user's preferred utility.

<OT>Incidentally, one thing that _really_ irritates me about Moz is that, when I
associate it with .html files, it then associates composer with the edit command
(I'm talking windows here, of course).  But I don't use composer to write html. 
I use Lemmy. Must raise a bug rep about that...
</OT>
Peter: You are more capable than most browser users. Not shipping any text 
viewer with Mozilla would make it hard for users who don't know what they are 
doing. Many users don't even know what plaintext is. Has anyone checked the 
size of the files for source view? I bet (I haven't checked) it is not more 
than 80k uncompressed and 5k compressed. The new features might double that at 
most. 10k is not my idea of code bloat. It would be nice to make it modular so 
that people could disable its installation if necessary (but its probably best 
to install it by default).
dependency is the OTHER WAY.
No longer blocks: ExternalViewSource
Depends on: ExternalViewSource
Assignee: ian → doronr
Product: Browser → Seamonkey
Assignee: doronr → mrbkap
QA Contact: pmac → doronr
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Assignee: mrbkap → nobody
QA Contact: doronr → view-source
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
Product: SeaMonkey → Core Graveyard
You need to log in before you can comment on or make changes to this bug.