Closed
Bug 8589
(ExternalViewSource)
Opened 25 years ago
Closed 15 years ago
make view source optionally open in text/plain helper app
Categories
(SeaMonkey :: General, defect, P3)
SeaMonkey
General
Tracking
(Not tracked)
RESOLVED
FIXED
seamonkey2.1a2
People
(Reporter: csbooton, Assigned: smontagu)
References
Details
(Keywords: helpwanted, Whiteboard: [Hixie-P0][Hixie-3.0][MB][Goat-p1])
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
smontagu
:
review+
smontagu
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
IE uses this and it can be very useful dpeending on the user, in fact several people who use IE site this as one reason to only use IE . So, how about a feature that would make it so that you have the <b>option</b> of having view page source open in notepad (or your default html editor or an application of your choice). For people editing their own pages or wanting to fix their own pages this could be a great option.
Updated•25 years ago
|
Assignee: beard → rickg
Component: Views → Parser
Comment 1•25 years ago
|
||
This would be a nice general feature, for all platforms. View source should be
able to use any helper application.
URL: any
Component: Parser → other
Summary: not a bug but a feature request - how about an option tomake view source open in notepad → [RFE] Option to make view source open in notepad
Target Milestone: M14
Updated•25 years ago
|
OS: Windows 98 → All
Comment 3•25 years ago
|
||
I agree, I would suggest a 'View > Source' and 'View > Edit Source' option.
This could be linked at bug #14526
Updated•25 years ago
|
QA Contact: beppe → paulmac
Comment 5•25 years ago
|
||
assigning Paul as QA contact
Comment 6•25 years ago
|
||
I don't see that this is necessary. As far as I can see you'd only want to do
this to edit the source, in which case bug #14526 covers this within Composer.
It's not as if Notepad has a huge number of features, so the page source editor
could only be better.
A better idea might be to allow disabling of Composer and redirecting all "Edit
Page" requests to a user-defined editor (eg Notepad).
Comment 7•25 years ago
|
||
What reasons are there to want to do this? For those who do, what features in
the editor would make you use it instead? Can you submit bugs on them?
Comment 9•25 years ago
|
||
All it would take to satisfy the original RFE would be to make the plain-text
editor (designed for Mail/News) available on a menu in a form that would not
attempt any html->plain text or plain text->html translations. This would eat
notepad for breakfast. But there is a better way to provide a general
solution - allow some applications defined in the Prefs UI to be "manual"-only.
What reasons for making an arbitrary external app available from Mozilla for
viewing/editing source? The answers don't start with notepad. (The reporter
failed to mention that notepad is the *default* for viewing source with IE -
and there is nothing as useful as Navigator's View Source available.)
1. To cater to the needs and wishes of those who prefer to mostly use Mozilla
without being locked into a Mozilla-only environment. This should be reason
enough, but consider: those who most need easy access to multiple ways of
working are the very web professionals who are about to find out that
Microsoft-centric semi-adherence to HTML4, CSS, DOM, etc isn't going to be
enough any more. Do you really want to make it harder than necessary for these
people to go from viewing a page with Mozilla/Nav 5 to viewing/editing it with
the tools they are used to using or even, in some production environments,
must use, when there are so many little gotchas they may find in their code
viewing it in Mozilla?
2. Workflow. This goes with 1. Without this feature, to use any external app
requires saving the source file (navigating to some specific location if that
matters), opening the helper app, navigating to the location where the file
got saved to to open it. Now imagine that the snippet of source you thought
you'd find in that page isn't there. Only tens of seconds wasted, at most,
but anyone used to working with any sort of programmer's editing environment
is going to be annoyed. With the feature, the file would come up in the app
first, and whole sequence of saving and navigating the directory tree would
only be needed if there is any reason to keep the source for later.
3. No matter how good view source and compositor may be or become, they
can't ever be the best for all purposes. For example, with Textpad
<URL:http://www.textpad.com/> I can set up syntax highlighting however I want,
and do regex searches and replacements in the source file. With Macromedia's
Dreamweaver, <URL:http://www.macromedia.com/software/dreamweaver/> it is
possible to edit a typo or even add elements without taking any chance of
messing up the formatting of a source file prepared by a
database->web->database->web gateway. There are also editors that present a
navigable DOM of the entire page - allowing quick navigation to the code for
any part of the page. Some helper apps can reliably parse HTML and give an
accurate word count or other stats. And then there are the graphical front-ends
for HTML Tidy <URL:http://www.w3.org/People/Raggett/tidy/#download>. Some of
those features may be nice to have within Mozilla, but Mozilla can't be
everything to everyone.
(Personally I don't feel inclined to submit RFE bugs for composer or view
source that would add entire new features before late beta at the earliest,
when those features are already available to me in other apps - the engineers
are busy enough now as it is. Time enough later to play feature-catchup.
Having said that, the RFE already in bug 14526 (dual-mode editor) is the first
I'd ask for, and integration of HTML Tidy is the second.)
4. It needen't be hard to do this properly.
There is a simple and completely general way that this could be done:
allow [New] apps defined in the Applications pane of the Prefs UI
to record whether a given helper is "Auto" or "Manual" (a simple flag).
A manual app would normally be set up for a mime type that already
has an auto app defined, and would be used only as a user-triggered alternate.
Auto apps would be invoked by default triggered by mime type as now,
whereas manual apps would be added to a "Helpers ->" submenu or possibly
an "Applications" menu as prefs.js or the registry is read in at startup.
The user could invoke on the current file whatever helper app is useful in a
specific circumstance with just a few keystrokes or mousing actions - and
invoke a different one five minutes later.
This would be a completely general solution to the problem of allowing
choice during a session, without unhooking the default application for any
action. Anyone who has ever taken a tech support call from someone who
has unhooked a default app (in any environment), or can imagine it, will
understand why it would be good to allow the use of alternates without
unhooking the default app. (Allowing Composer to be disabled would be
a horrendous example of a set-up for a nightmare tech support call).
5. Sometimes the added value of the syntax highlighting that view source
does isn't worth the time it takes. If all I want to do is grab two lines
out of a stylesheet in the <title>, I don't *really* want an unknown wait
first. View source would have to be consistently an order of magnitude
(base 16) faster before this concern would become a total non-issue.
Comment 10•25 years ago
|
||
Move to M20.
Comment 11•25 years ago
|
||
Another reason you might want to use notepad: mozilla's view source thing is
hard to copy text out of. It tries to ignore the less-than and greater-than
parts of HTML tags when you copy text out.
Comment 12•25 years ago
|
||
This sounds like a bug in Mozilla, not support for this bug. It's probably
already been fixed by now or at least been filed by someone.
Comment 13•25 years ago
|
||
spam: moving qa contact on some bugs from paulmac to sairuh@netscape.com
QA Contact: paulmac → sairuh
Comment 15•24 years ago
|
||
*** Bug 43073 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
pardon the spam: moving view source bugs into xp apps: gui component.
Component: Tracking → XP Apps: GUI Features
Comment 17•24 years ago
|
||
Ccing myself and Hurricane (rcassin@supernova.org)
I think this feature would be nice and is close to bug 35268, but should be kept
as a seperate feature as one might want a seperave view source program vs
external editor.
Updated•24 years ago
|
Keywords: helpwanted
Updated•24 years ago
|
Summary: [RFE] Option to make view source open in notepad → [RFE] Option to make view source open in text\plain helper app
Updated•24 years ago
|
Summary: [RFE] Option to make view source open in text\plain helper app → [RFE] Option to make view source open in text/plain helper app
Comment 18•24 years ago
|
||
*** Bug 58438 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
*** Bug 59155 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
Here are my comments from bug 59155 and a bit more:
I was reading n.p.m.wishlist, and I saw a lot of references to IE's loading
source code in notepad. So here's an rfe.
1) Include the ability to hook the View Source command up to the program that
is specified for "Edit" in Windows File Types (Win only). In Windows IE this is
usually Notepad, Word, or Frontpage.
2) Include the ability to specify a program to view the source code in. (I
would use xemacs on unix)
Implementing this would give many users an advantage by being able to use their
favorite editor to do all the things that mozilla view source does and more
(cut and paste, syntax highlighting, regexp searching, etc.). It would also get
rid of many complaints about the syntax coloring issue (bug 52154).
As far as I know, the way IE does this is to pass the temporary file from the
cache to the external program via command line.
I think this should be included in mozilla1.0. Why reinvent the wheel (view
source) when there are so many great text editors out there. I think it should
even be default if implemented.
> This sounds like a bug in Mozilla, not support for this bug. It's probably
> already been fixed by now or at least been filed by someone.
What do you mean by that?
Comment 21•24 years ago
|
||
*** Bug 60424 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
*** Bug 60597 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
Sorry for the dupe..this is a must-have for me.
cc:ing self.
Comment 24•24 years ago
|
||
Hello, my bug was marked a dupe. Adding CC.
Comment 25•24 years ago
|
||
Mozilla should have a built in text editor for the default helper app that comes
with it, but someone should be able to change it to notepad (why they would is
beyond me). This Mozilla text editor should have an option to make all tags a
certain color based on what they are.
Comment 26•24 years ago
|
||
I also agree that composer should not be used at all to view source. It would
make a lot of people twiddle their thumbs. Twiddling thumbs is bad.
Comment 27•24 years ago
|
||
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
Vishy
Assignee: don → vishy
Comment 28•24 years ago
|
||
*** Bug 63497 has been marked as a duplicate of this bug. ***
Comment 29•24 years ago
|
||
*** Bug 63497 has been marked as a duplicate of this bug. ***
Comment 30•24 years ago
|
||
My $0.02
The built in view-source function doesn't do what I want it to do.
gvim does everything I want it to do.
Even if the built in view-source did what I wanted, I already know how to use
gvim and it's set up to my liking.
This feature request is *VERY* desireable to myself and other developers in my
group.
With more developers using your broswser, you'll get more pages made for your
browser, and therefore more users using your browser.
Comment 31•24 years ago
|
||
*shrug*, if you want to do it go ahead; we're accepting [good] patches. however
you should be able to pick a text helper app for composer [which can actually
function as a browser]...
Comment 33•24 years ago
|
||
I too would like a pref to choose an external editor/helper app.
What about for embedding where a context click could have view source but
composer isn't installed? I guess embeding vendors could whip that up easily.
Hardware: PC → All
Comment 34•24 years ago
|
||
I personally think that a simple text editor with ability to display line
numbers and replace/search for text could be included in mozilla and be the
default helper app. ie: the default helper app would be "texteditor" or
something (and could be changed) which would let mozilla know to open the text-
editor built into mozilla.
Composer is no option since everyone doesn't install it (I think).
The text-editor could be a simple XUL Box with a menu bar and an XUL Frame, and
a status box at the bottom. The status box would show the line:col.
This needs to be fixed soon as this is the _MAIN_ reason keeping a lot of
people from using Netscape-type browsers.
Comment 35•24 years ago
|
||
line numbers sounds like a good rfe for view source, filed bug 70868.
currently composer ships w/ navigator, i never got around to completely
splitting it out.
Comment 36•24 years ago
|
||
10 dups according to http://bugzilla.mozilla.org/duplicates.cgi. Marking mostfreq.
Keywords: mostfreq
Comment 37•23 years ago
|
||
Excellent commentary, Mr. Richardson. You've made a compelling argument.
Adding CC.
KNode, a KDE newsreader, allows you to set an external editor.
Screenshot: http://www.kde.gr.jp/help/doc/kdenetwork/doc/knode/HTML/knode-
composer-settings.png
Perhaps the KNode source could point the Mozilla team in the right direction?
http://knode.sourceforge.net/
Comment 38•23 years ago
|
||
No, we can switch the HTML composer into a plaintext editor if we need to, and
I'm working on some stuff which will allow a document to be loaded directly into
a plaintext editor (currently, the only way to access plaintext editing in the
editor is to open a .txt document, or to go to the Debug menu and click
Plaintext Editor)
What do we want here? A menu/button in the view source window that will pop open
an editor in plaintext mode with the HTML source there? ...I can do that, it
shouldn't take long at all. Just need a little feedback and I'll be on my way.
Comment 39•23 years ago
|
||
I would vote for an option in preferences to define the external application (if
any) to be used when viewing source. a separate menu item might be annoying,
especially if it was not available by right-clicking the page.
Comment 40•23 years ago
|
||
Just my .02
I would like to see a menu option in the main mozilla browser (like IE) but
could live with the menu under the view source window. Seems like an extra step
to me.
I think that the most important part to this bug is to allow someone to select
what application they want to use as an editor (not just the one that comes with
mozilla). For me it's TextPad. In IE, I can change my editor to TextPad. This
is the main reason why I do not solely use mozilla.
Comment 41•23 years ago
|
||
rcassin: I think the best option would be a simple notepad-like editor built
into the source (possibly composer embedded in a small window - if it comes up
fast) as the default helper app. Then composer could be a secondary helper app.
Finally one could pick something on the operating system.
This default helper app need not do more than word-wrap / non-word wrap, search,
replace, [cut, copy, etc], print, and view and save in either unix, mac, or
windows text format.
The basic idea here is it should be fast. Faster than loading a browser window
hopefully, and faster than loading composer. Possibly, also a different thread
so it doesn't crash with Netscape (in case Netscape crashes). If that wouldn't
work, then it could be a seperate xpcom program. (Maybe there are even simple
xpcom text editors out there).
Comment 42•23 years ago
|
||
By Netscape I meant Mozilla, and don't forget the ability to open files and
spawn new text windows.
Comment 43•23 years ago
|
||
Netdemon: We already have plaintext editor capabilities in the editor. Go into
the editor and open a .txt file. The HTML composer changes into a plaintext editor.
My suggestion was to have a way to open the page you're at in the browser open
in the plaintext editor. There is an easy way to get this done, and it works as
a temporary fix to this bug. I realize that we still couldn't open the source in
an external editor, but something is better than nothing?
Comment 44•23 years ago
|
||
rcassin, *sigh*. As I said, I don't want composer loaded when all I want to do
is view the source, and maybe do a couple changes and save it to the disk. Maybe
you coulc have a button in the view source window that could transer the
document over to composer, but composer is not my idea of a text editor.
Lets put it this way: would you want Word to load in text format just for
viewing the source of a web page?
If you look at what I said, I was basically saying that composer, although it
has text editing capabilities, is not good for this.
>rcassin: I think the best option would be a simple notepad-like editor built
>into the source *******------{{{{{{ LOOK HERE: (possibly composer embedded in a
small window }}}}}}}------****** - if it comes up
>fast) as the default helper app. Then composer could be a secondary helper app.
>Finally one could pick something on the operating system.
>This default helper app need not do more than word-wrap / non-word wrap, >search,
>replace, [cut, copy, etc], print, and view and save in either unix, mac, or
>windows text format.
>The basic idea here is it should be fast. Faster than loading a browser window
>hopefully, and *******------{{{{{{ LOOK HERE: faster than loading composer.
>}}}}}-----******* Possibly, also a different thread
>so it doesn't crash with Netscape (in case Netscape crashes). If that wouldn't
>work, then it could be a seperate xpcom program. (Maybe there are even simple
>xpcom text editors out there).
Comment 45•23 years ago
|
||
The Plaintext Editor is NOT composer. (In fact the plaintext editor got
forgotton when the component bar was added to Mozilla's status bar). The
difference is similar to the difference between Wordpad and Notepad.
Also, Composer 4.x had an external edit option, so this bug is 4xp.
Comment 46•23 years ago
|
||
Up to trudelle. Sounds like something Paul Chen might do?
Assignee: ben → trudelle
Comment 47•23 years ago
|
||
Sounds very useful to a tiny number of people, but almost certainly not
something we'd be able to spend NS engineering time on.
Updated•23 years ago
|
Component: XP Apps: GUI Features → File Handling
Comment 48•23 years ago
|
||
What this all comes down to is a simple matter of choice. The whole basis of
the Open Source movement is freedom to choose... not imposing your will or your
way of doing things on others. This seems to me to be a simple matter... there
would be many people out there, myself included, who would benefit from the
option to choose our own editor/viewer. If you have people asking for the
feature, and it would not be a huge problem to do it, why not do it? It won't
effect standards compliance, or degrade the application in any way. It would
simply be a feature that many people have come to expect and depend on when
developing web content.
Mozilla has come a long way in the past few years, and at this point may very
well be a model for how to put out a quality, standards-compliant piece of
software. But it's those little extras, those little features that make life
easier, and help with the mainstream acceptance of Open Source projects.
We should keep the spirit of choice alive, even in the small details.
Comment 49•23 years ago
|
||
and in that great spirit, you can submit a patch...
Comment 50•23 years ago
|
||
...and if anyone chooses to attach a patch, we'll certainly spend the time
needed to consider it.
Comment 51•23 years ago
|
||
*** Bug 120550 has been marked as a duplicate of this bug. ***
Comment 52•23 years ago
|
||
Please note that this would also provide a (pretty good!) workaround for all the
bugs relating to the way 'view source' processes the HTML (and accordingly fails
to represent it accurately).
Comment 53•23 years ago
|
||
But I hope you will not remove standart View Source?
Comment 54•23 years ago
|
||
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).
Whiteboard: [Hixie-P0][Hixie-3.0][MB]
Comment 55•23 years ago
|
||
Could you tell us, please, why do you think that user shouldn't have an ability
to view page source with the included comfortable View Source application. Yes,
you are right, there should be an option to open source in external application,
or to replace standart View Source with external application. Some people prefer
to use Notepad or HomeSite, and now they have no ability to use it. But why do
you think that there is no user in the Earth that could prefer to use internal
View Source??? For example, I want to have BOTH options, because usually I use
View Source, but sometimes I want to open it in external HTML editor, and I saw
those who think the same.
I can understand, that you try to make Mozilla absolutely same as Internet
Explorer (however, I cannot agree with this position!), but why do you think it
should have all the Explorer defects and imperfections??
Comment 56•23 years ago
|
||
I agree with Alexander. Just give the option to change it to editor, notepad,
or whatever else.
Comment 57•23 years ago
|
||
hixie: i don't think it is a good idea to dump the internal 'view source'
viewer, since it got pretty cool with the time. It is much better now then what
most of the non technical users will have.
Comment 58•23 years ago
|
||
FWIW, in my opinion we should definitely delegate whatever we can to the OS
currently running; that means opening the source in the user's favorite
text-editor. If you would desperately want a XUL view-source application
(why?), I'm sure it wouldn't be hard (after this was fixed) to revive it as an
XPI on mozdev.org.
Comment 59•23 years ago
|
||
> in my opinion we should definitely delegate whatever we can to the OS
> currently running
I disgaree - after all we are not delegating a mailreader or newsreader to the
outside apps, even if we could. I like the current view source and I do not even
need an external app in 99% of the cases. And after all, opening a window in
Mozilla is faster than starting some external app.
In any case, even if we end up getting rid of the internal viewer *it's
definitely a separate bug*! Let's make the external app *an option* as this bug
requests, live with it for a while, see how it works and then we'll be in much
better position to decide whether we still need the internal view source.
Comment 60•23 years ago
|
||
Comment 61•23 years ago
|
||
If it's decided that the internal viewer should stay, I'm all for modularizing
it so that people who don't intend to ever use it don't have to install it (like
with mail/news, psm, etc).
Comment 62•23 years ago
|
||
Really, delegating it to another app is making our code depend on another
application working/existing/etc. How do we know that the OS has what viewer
we delegate it too? Say you choose xemacs in linux: People can install linux
without xemacs. If you think its alright that they have to do a one-time
setting, think about developers who might install it many many times and try
many different profiles. Think, also, about all the developrs who have worked
on it. You are going to throw their work away even when some people like the
current view source? If we make it an XPI, at least half the people running
mozilla/netscape won't know they can get it. I agree with modularizing it as
long as it comes by default on the .zip and .tar.gz binary files and also
exists by default when building with the source tree.
Comment 63•23 years ago
|
||
> Could you tell us, please, why do you think that user shouldn't have an ability
> to view page source with the included comfortable View Source application.
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.
Platforms always have an editor of some kind. On Unix systems the editor is
specified using $EDITOR as a last resort. All three main platforms have official
ways of finding the user's preferred editor. (This should certainly not be a
Mozilla-specific pref.)
Note that if we don't let Mozilla integrate with other mail/news applications,
that that is a bug and not a feature.
Assignee: trudelle → doron
Severity: enhancement → normal
Component: File Handling → ViewSource
QA Contact: sairuh → pmac
Summary: [RFE] Option to make view source open in text/plain helper app → make view source open in text/plain helper app
Comment 64•23 years ago
|
||
> 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
That would be completely useless. If I choose `View Source' for a text/html file,
I expect to view the source of the file (`<!DOCTYPE HTML PUBLIC "-//W3C...'), not
the page itself mangled in FrontPage or Composer. And if I choose `View Source'
for an image/png file, I expect to view the source of the file
(`âPNG
IHDR
Comment 65•23 years ago
|
||
...), not see the image itself in PictureViewer.
> Because we are a web browser, not a source viewer.
Speak for yourself; I'm not a Web browser. I do, however, have five Web browsers
on my computer (not counting different versions of the same browser), and *every
one* of them disagree with you. They all have dedicated source viewers; and all
these viewers (modulo bugs in Mozilla) have the same set of menus as the browsers
themselves, an advantage which an external editor could never achieve.
In theory, it would be nice if we could say `Mozilla is a Web browser, not a
source viewer', `Mozilla is a Web browser, not a search tool', `Mozilla is a Web
browser, not a bookmarks manager', `Mozilla is a Web browser, not a cookie
manager', and so on. In many of those cases (as with mail/news) it would be nice
if Mozilla's implementation of those features was implemented as a separate
process. And it would be nice if I could choose to delegate those tasks to
external apps. But to say that they *must* be delegated to external apps is
entirely unreasonable, given that Mozilla's implementation of most of them --
including its implementation of source viewing -- is an order of magnitude better
than that available from any alternative program on a default Windows or Mac OS
installation.
Comment 66•23 years ago
|
||
I agree with Hixie's point (nothing new here). Moving away from an internal
mozilla viewer to the OS default source viewer would be a wise choice and is a
better use of limited resources.
Matt your comment #65 seems wrong to me because (unless one of your 5 browsers
isn't IE), IE (with what 95% of the browser market) has always defaulted to the
OS when it comes to view source (textpad) in windows (there is a pref to change
to a different app -- TextPad for example) and I'd bet IE does the same thing in
Mac.
Comment 67•23 years ago
|
||
> I do, however, have five Web browsers on my computer
> (not counting different versions of the same browser),
> ... They all have dedicated source viewers
In Netscape 2.0 you can edit netscape.ini and change the HTML editor.
In Opera, the default viewer is write.exe, and you can change it.
In IE, the default viewer is notepad.
So what do you have, Mozilla, Amaya, and Lynx?
> all these viewers have the same set of menus as the browsers
> themselves, an advantage which an external editor could never achieve.
How is a this an advantage? Now you can text-zoom and word-wrap?
Is there something I'm missing?
The internal viewer is slow. Viewing the source of
http://www.timelapse.com/tvlink.html leaves you staring at the hourglass for 10
seconds in Moz. It's instantaneous in IE with Textpad.
Comment 68•23 years ago
|
||
I already said this in comment #59, but I believe it is worth repeathing. *This*
bug is about adding an *option* to view source in an external app. Those who
think that the current internal view source should go (personally, I strongly
disagree) are welcome to file a *new* bug on that!
To quote the original reporter:
> So, how about a feature that would make it so that you have the <b>option</b>
of having
> view page source open in notepad (or your default html editor or an
application of your
> choice).
(the <b> on option comes from the original reporter).
Comment 69•23 years ago
|
||
I agree with Aleksey Nogin. And I should remember some of you you again: there
are A LOT OF PEOPLE wanting to use internal viewer because they think it's
comfortable. If you want to force them to search for another application, that
is as comfortable as internal viewer, you should remove Modern Theme because you
don't like it, and remove Mail&Newsgroups because it is too slow and less
comfortable than TheBat, and remove Preferences because you know better than any
other people, how it should be customized! You don't want to remove Modern Theme
and Mail&Newsgroups? Well... That's strange! So why do you want to remove View
Source? Oh, I know! You think that it's easier to remove an app than to make it
better. So, remove Navigator, because it has a lot of bugs!
�� до �его же неко�о��е �о��� ��о-ниб�д� �б�а��!
Comment 70•23 years ago
|
||
Actually, I do want to remove mail and news (see bug 115903). And as some people
have noticed, there is a concerted effort to reduce the size of the preferences.
And the View|Apply Theme menu is being removed too. So all in all, we are doing
exactly what you say we should be doing to be in line with removing our internal
view source implementation (and its 100+ bugs).
mpt: given the many bugs in our view source implementation, especially those
that _change the source_ of what you are looking at, I doubt that we really are
better than anything else that ships on Windows or Mac.
Comment 71•23 years ago
|
||
Filed bug 145021 for this. Please take further discussion there so this bug can
return to its original purpose (i.e. letting people choose what they would like
to view source with, including the internal source viewer).
Another bug that might be of interest is bug 13474 (external processes/filters
for textareas), which currently has a preliminary patch.
Comment 73•23 years ago
|
||
Letting my goats fix this for me, expect it done around bugzilla 3.0
Whiteboard: [Hixie-P0][Hixie-3.0][MB] → [Hixie-P0][Hixie-3.0][MB][Goat-p1]
Comment 74•23 years ago
|
||
> Actually, I do want to remove mail and news
That's bad. I beleive in you, you, may be, want to remove browser too. May be,
you think that all that Mozilla does, the other soft does better...
> So all in all, we are doing
> exactly what you say we should be doing to be in line with removing our internal
> view source implementation (and its 100+ bugs).
So, I totally disagree with your conception. I thought, that we are DEBUGGING,
but I was not right. Actually, we are REMOVING. I don't like this process. If
all will come this way, I will use Mozilla 0.99 or other old build, or
Communicator 4.79, because Mozilla will use only external applications all the
time. I'm sorry, but I thought that in this century browser is not ONLY a
browser. I was not right. All the browsers except for Netscape are not only
browsers. Netscape will be ONLY Navigator, without Mail, News, Composer,
Debugger, Java, PageInfo, Security Manager, Password Manager, and even View Source.
You are tired of debugging, so you say: "our product will never be better than
all the others!" I do not agree with you - I think, we SHOULD try TO MAKE IT
BETTER, THAN THE OTHERS! But if we will look at it as at MsOffice, which is
already developed, and will never be better, then there will come a day when
Mozilla will be only a browser.
> mpt: given the many bugs in our view source implementation, especially those
> that _change the source_ of what you are looking at, I doubt that we really are
> better than anything else that ships on Windows or Mac.
You say: "TheBat is better than Mozilla Mail. HomeSite is better than Mozilla
View Source. And Mozilla chat client isn't the best in the world." So, all users
have to search for the separate application for each small function. What's
next? Will you say that Navigator isn't the best browser, and we must throw it
out?? I'm waiting.
P.S. I know what is your slogan. It is:
LET US IMPLEMENT ALL THE IMPERFECTIONS OF MICROSOFT INTERNET EXPLORER IN MOZILLA
AND REMOVE ALL THE COMPONENTS THAT CONTAIN UNFIXED BUGS!
But I do not think that this is what we should do.
Yours faithfully,
Alexander
Comment 75•23 years ago
|
||
I don't think Hixie is saying that the Mozilla project should only make a
browser. I think he is saying that the browser, mail, news, view-source,
etc... should all be separate sub-projects which are optional to use. In
addition, he is saying that a crasher bug in, say, mail, should not bring down
the Mozilla web browsr and vice-versa.
Bugs might be more manageable if they didn't affect everything else. If IE
crashes, it doesn't bring down Outlook Express with it.
In this senario, view-source would be available to you, but as an option.
Think of an installer where it would ask you, "do you want mail/news, view-
source, browser, etc...". What about people who just like Mozila's Mail app a
lot, but don't care to use the browser (only theoretical...who wouldn't want to
use the Mozilla browser?). They should have that choice. Why require the user
to have Chatzilla, Composer, the browser, etc... when they just want mail/news?
For those who think some of these components should be scrapped, I'd say that I
wholeheartedly disagree with your sentiment. However, I don't think anyone is
actually saying that...or actually meaning that even if their words could be
misconstrued as implying that. bug 115903 and bug 145021 look like very nice
solutions to me. Mozilla is supposed to be componentized in an effort to be
more embeddable and to reduce unnecessary bloat. Let's not let this effort get
lost in accusations that people are out to ruin the Mozilla suite...least of
all Hixie.
Jake
Comment 76•23 years ago
|
||
Thank you, Jake!
I'm sorry, but Hixie wrote that he wants to remove View Source and he wrote
"Actually, I do want to remove mail and news".
>the browser, mail, news, view-source,
>etc... should all be separate sub-projects which are optional to use. In
>addition, he is saying that a crasher bug in, say, mail, should not bring down
>the Mozilla web browsr and vice-versa.
>
>Bugs might be more manageable if they didn't affect everything else. If IE
>crashes, it doesn't bring down Outlook Express with it.
I agree with all that you wrote including what about "separate sub-projects
which are optional to use". All installed components should be avialable through
the menu (Tools or Window), but when one component freezes or crashes, it
shouldn't crash all the others!
>Think of an installer where it would ask you, "do you want mail/news,
>view-source, browser, etc...".
Good! I think, it's one of the best solutions. May be, simply the best solution.
And one small thing... After the installing user should have an option to use or
not to use by default these components, including Mail and View Source. If he
installed View Source, he should have an ability to access BOTH View Source and
external HTML editor from the menu/context menu or to switch it in the
Preferences, like this:
Source Viewer
[ ][Browse...][Restore default]
or this:
Source Viewer
( ) Default
(*) Other:
[ ][Browse...]
or this:
Source Viewer
External
[ ][Browse...]
Show in menu
( ) Default
( ) External
(*) Both
>bug 115903 and bug 145021 look like very nice
solutions to me.
Yes. 115903 will increase stability and make Mozilla more comfortable. As for
145021 ... May be.
Comment 77•23 years ago
|
||
Please see bug 145640 about having both internal viewer and helper application
available on the menu system or equivalent.
Comment 78•23 years ago
|
||
*** Bug 143409 has been marked as a duplicate of this bug. ***
Comment 79•23 years ago
|
||
Let me just reiterate that while I believe there should be a user pref for this,
Mozilla's pref dialog is not the appropriate place for it. It should be in the
GUI shell -- on Windows, it's the File Types editor, for instance.
Comment 80•23 years ago
|
||
I believe it should go in the helper applications section of Mozilla not under
text/plain but as application/x-sourceview or something.
Comment 81•23 years ago
|
||
Or maybe the OS under something like application/x-sourceview or text/src, but
text/plain is mapped to notepad under my system, which isn't what I would want
to use for editing pages, but is perfectly fine for some files. For editing
pages, I would want to be able to choose a separate program from notepad without
affecting my association for text/plain.
I still believe the proper place for this is a permanent entry in helper
applications in preferences that opens an alternate "Edit Type" window that
gives more options than a manually created entry.
Why does this bug depend on bug 145021? You can create the ability to open in a
text/plain helper application without bug 145021 being fixed. How can you fix
bug 145021 without this one being fixed, though? If that one is fixed first,
there will be no view-source ability even in a helper application if someone
chooses not to install view-source. Shouldn't this bug block bug 145021?
Comment 82•23 years ago
|
||
Who said the view source component should be optional?
Comment 83•23 years ago
|
||
Nevermind, bug 145021 does. /me wakes up some more.
Comment 84•23 years ago
|
||
This bug does NOT depend on bug 145021. Someone who can should change the
dependency. Bug 145021 might depend on this bug.
Reminder: this bug is about allowing the *option* for view-source to open in a
text/plain helper application, not for *requiring* it. The summary should be
changed too.
Comment 85•23 years ago
|
||
Effectively, they are the same, since the correct way to implement this (as
described in comment 54 and especially in bug 145021 comment 2) would be to make
the source viewer component the default source viewer component. The pref to
change which source viewer you use is an OS-level pref, not a Mozilla-level pref.
Comment 86•23 years ago
|
||
Hixie, I don't know what OS you are using, but the OS I am using (W2K,
unfortunately) does not provide an OS-level pref that allows me to distinguish
viewing HTML from viewing HTML source from editing HTML from editing HTML
source. I only have the choice of what to view HTML with (e.g. Mozilla browser),
and what to edit HTML with. (e.g. Mozilla composer)
I prefer the current internal Mozilla source viewer for taking a quick look at a
webpage to see what was sent or how something works. I would never choose the
source viewer as my default HTML viewer or default HTML editor, which appear to
be the only choices this OS lets me configure.
If you can inform me where the OS-level configuration for HTML source viewer is,
please go ahead. We'll need the text for the release notes if your preferred
solution is ever implemented.
Comment 87•23 years ago
|
||
Explorer, Tools, Options, File Types, Edit. You can add any action you like.
Comment 88•23 years ago
|
||
Ok, so as I understand it, what hixie is proposing (modified to allow view
source separate from edit) is:
Windows
-------
View Source on non-local files should save the file to a temporary place and
launch the newly invented proprietary Mozilla "View Source" action 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 "View Source" command of text/html
files, for image/png it should similarly launch the default "View Source"
command of image/png files). If there is no "View Source" command, then it
should use the Edit command. 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.
Installing the optional View Source component would then ask if you wish to
associate it with the new "View Source" action on HTML (and XML?) files.
Linux and Mac
-------------
Similar, using the equivalent on these platforms. Linux would fall back to
(the newly invented proprietary) $SOURCE_EDITOR and (the standard) $EDITOR.
I suppose this wouldn't be too bad, though I really don't think it is the place
of Mozilla to invent new OS level prefs for things like this. It seems far
simpler to me to simply have a preference in Mozilla for what program to use for
viewing source, with an option to fall back on the OS default editor.
Overall, I really don't care how exactly it gets resolved, as long as it is
still possible for me to easily choose to use the built-in Mozilla source viewer
*and* relatively easy to choose an external helper app for viewing source as well.
Personally, I would prefer to be able to choose which to use right when I choose
to view source, like in IE where the "Edit" toolbar button also has a drop down
to choose which editor to use. I believe that is already filed as bug 145640.
(or its currently unfound duplicate.)
Comment 89•22 years ago
|
||
Yes, that is what I am proposing. Note that it also allows "View Source" (or
whatever the equivalent is called) to work on images, PDF files, XML documents,
CSS sheets, JS scripts, and other file types which Mozilla's source viewer
doesn't yet support.
(I'm not convinced this is a "new" pref. Absolutely no new UI is added anywhere.)
Comment 90•22 years ago
|
||
Just wanted to note again, I am the wrong person to be the owner of this.
Probably belongs in file handling or whatever component handles helper applications
Comment 91•22 years ago
|
||
-> File Handling then
Assignee: doron → law
Component: ViewSource → File Handling
QA Contact: pmac → sairuh
Comment 92•22 years ago
|
||
what happens if i try to view-source: a never ending file? (i've asked someone
to check about mozilla's view-source: handler)
Comment 93•22 years ago
|
||
view-source: is a hack and shouldn't exist... if you mean "what happens when you
the view the source of a never ending file", then I guess the same happens as
when you download an infinite file and open it in a helper app (since this is
effectively the same thing).
Comment 94•22 years ago
|
||
*** Bug 151319 has been marked as a duplicate of this bug. ***
Comment 95•22 years ago
|
||
Hixie: I don't agree with View Source being removed, but I do agree with it
possibly being made as something that isn't required for the installation or
building of Mozilla. Perhaps it could be hosted on Mozdev and improved by
outside programmers who could improve it, make it editable, add line numbers,
remove all issues, etc. When people want to use it, they could be given a link
to the .xpi on Mozdev when they choose View Source but have no helper
application defined. Once all the issues are resolved by developers who have
time to work on this, it can be reintroduced as part of the tree.
Comment 96•22 years ago
|
||
*** Bug 158942 has been marked as a duplicate of this bug. ***
Comment 97•22 years ago
|
||
*** Bug 162091 has been marked as a duplicate of this bug. ***
Comment 98•22 years ago
|
||
I'm a web developer, and I can't use Mozilla for development because of this
bug. I absolutely vote for user choice for what does View Source.
You CAN'T make a better text viewer than what I use, because what is best
depends on user prefence. I use Wordpad, hubby uses Editpad. I don't care what
features or bugs are present or absent in a text viewer, unless it looks and
acts EXACTLY like Wordpad, it is *not* best for *me*. Unless it looks and acts
exactly like Editpad, it is *not* best for my husband.
If I need a WYSWIG editor for some reason, I want my old out-of-date version of
Dreamweaver - NOTHING else. And I want to view graphics in *my* chosen graphics
program, which is not the PaintShopPro hubby uses.
Before Mozilla, he used Navigator, I used IE. With Mozilla, our themes and
skins and preferences and plugins are completly different. Our browsers look
MORE different now than when we were actually using different browsers!
In any scenario, increasing user choice is the best thing.
Status: NEW → ASSIGNED
Comment 99•22 years ago
|
||
THIS BUG AND ALL BUGS IN BUGZILLA ARE FOR TRACKING DEVELOPMENT WORK.
IF YOU WANT TO ADVOCATE SOMETHING, PLEASE GO SOMEWHERE ELSE. /dev/null is a good
choice. newsgroups are an ok choice.
Also, please don't futz with bug states, law didn't authorize you to accept the
bug on his behalf.
Alias: ViewSource → ExternalViewSource
Status: ASSIGNED → NEW
Comment 100•22 years ago
|
||
Fine, shall I create a patch which does this and watch it be rejected?
Comment 101•22 years ago
|
||
It will be accepted if:
1) UI for the user to choose the program
2) cross platfrom
3) current viewsource behaviour is default
However, if you really like getting rejected, I can do that too.
Comment 102•22 years ago
|
||
For doron's #1 on the last comment... The backend doesn't have to be done by
the same person as the UI.
Comment 103•22 years ago
|
||
This feature is definitely needed if you are doing web development. At the
moment, you really can't trust mozilla to show you the source as it is.
Sometimes you make a change to your code and something doesn't render quite
right. At this point you can't just open the source and see what might be
wrong. When working on Windows, I usually keep IE open just for cases like
that. (On linux I need to use a perl script that retrieves the page and dumps
it to a file, which I then open with emacs. This is a total pain, since you
can't easily paste a URL from Mozilla into the console window.)
Updated•22 years ago
|
Updated•22 years ago
|
QA Contact: sairuh → petersen
Comment 104•22 years ago
|
||
If nobody more knowledgable about Mozilla is actively working on this, I'm going
to try to take a stab at this this weekend, starting by adding do-nothing
backend options. (I think bug 57724 is the highest-priority bug in Mozilla,
although the silly Netscape people don't seem to agree; and fixing this is the
easiest way to get a work around for that bug. Until one of these two is fixed,
View Source is useless.)
By the way, this bug seems to be in the wrong component.
Comment 107•22 years ago
|
||
Nathanael, please consider a patch of
Bug 13474 : external processes/filters for textareas
Comment 108•22 years ago
|
||
Good God, Mozilla is poorly documented.
I can't figure out how to add a backend pref.
--Nathanael
Comment 109•22 years ago
|
||
Consider that a request: if anyone can point me to documentation indicating how
to add a back-end pref, or to which files back-end prefs are listed in, please do.
Comment 110•22 years ago
|
||
I would like to see View Source be able to use an outside editor - such as VIM or
GVIM. I think Doron's suggestion will allow that, but if not you should be able
to configure a editor specifically for viewing source.
I haven't played w/editing source via Mozilla, but there also you should be able
to configure the editor to use.
Great work - keep it up!
Comment 111•22 years ago
|
||
I vote for a new pref under navigation or Advanced, allowing the user to select
------------------------------------------------------------
View Source uses:
[ ] Internal viewer (*1)
[ ] Load source in Composer
[ ] Use external viewer/editor [full pathname input box] (*)
------------------------------------------------------------
(*1) even if the internal source viewer becomes better than all existing
editors, there should still be a choice...
(*) Where the user could enter a full executable pathname like:
c:\windows\notepad.exe %1
or
c:\utils\q.exe %1
(QEdit 3.0 rules ;)
or in linux
\usr\local\bin\joe
\usr\local\bin\vim
...or whatever
Of course the source would be saved to a temp file and then passed as argument
to the editor/viewer of choice.
This is TOTALLY unrelated to the issue of "if Composer adds a plaintext editor",
"if some user wants to use Composer", "how great composer is", "Why someone
thinks notepad.exe sucks".
Mozilla is and should continue to be about CHOICE. If the user prefers the built
in viewer, fine, it should be an option. If someone wants to load the source in
composer, FINE, it should be an option, and finally there should be an option to
use whatever third party app the user wants. Simple, isn't it?
I'm not making names... but it seems that some folks are too interested in
"defending" the status quo against any improvements. And "freedom of choice" is
clearly an improvement in my book. [Yes, matty@chariot.net.au, I'm talking about
you ;)]
Just my $.02
Fernando
Comment 112•22 years ago
|
||
I vote for this variant too. Yes, this will be the best solution!
And you should probably add special option for the case if someone on mozdev.org
will present alternative mozilla-based source viewer. (It could be connected in
[full pathname input box])
Comment 113•22 years ago
|
||
Mozilla is also about contributing code. So unless you can help in that area,
adding "I too want this" won't really help at all.
Comment 114•22 years ago
|
||
Please read comment 109 again. I'm willing to do this, and I can contribute
code. But I simply can't find where or how back-end prefs are put into the
codebase; the Mozilla codebase is a maze. I spent two days looking. If someone
can tell me where to find information about this, I'll start on it. :-P
Comment 115•22 years ago
|
||
Nathanael, I doubt that I know any more about the mozilla code base than you do
and may be totally out of line here but, since nobody else is responding to you,
it appears to me that nsExternalHelperAppService.h, and its parent directory,
would be a good place to start looking in order to fix this bug.
http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.h
However, based on your comments and my own short foray into the mozilla codebase
a while back, I wouldn't be surprised if you've already found this file and, in
the process, discovered that very few of the mozilla headers have even the most
cursory description as to what the class they define is supposed to do. This
means that, if you're new to the code, finding where a particular task is
carried out requires first browsing through a gazillion files that aren't what
you're looking for before you finally stumble upon anything remotely relevant to
what you want to do.
There're also a lot of headers that appear to have been removed from the
codebase, but are still referenced in various other files. For instance,
nsIMMEInfo.h and nsIServiceManger.h (which is, AFAICT, now
nsIServiceManagerObsolete.h).
But I'm getting off-topic here, so I'll digress :-)
Comment 116•22 years ago
|
||
write code first, we can deal with prefs later
Comment 117•22 years ago
|
||
If you want to "add" a back-end pref, you simply ask the pref APIs (see
nsIPrefBranch and nsIPrefService) for the value of that pref. You should make
sure that either there's a default value in all.js (considered the preferred
way, for some reason, perhaps as documentation) or that you fill in the out
parameter with a default value before the function call to the pref APIs so that
if the pref is not present (and they will return a failure nsresult), the out
parameter will be correct (since they won't modify it in that case).
Comment 118•22 years ago
|
||
*** Bug 198758 has been marked as a duplicate of this bug. ***
Comment 119•22 years ago
|
||
*** Bug 69329 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Depends on: input-helper-apps
Comment 120•22 years ago
|
||
Marked dependent on bug 46135 for helper input applications, so that the
text/plain helper application will be an editor instead of an (optional) viewer.
Comment 121•22 years ago
|
||
Memorializing the pertinent documentation, the result of bug 61408:
http://bugzilla.mozilla.org/attachment.cgi?id=112432&action=view
Depends on: 61408
Comment 122•21 years ago
|
||
Taking, guessing 1.7a.
Doron: if you want this earlier, please keep bug 46135 in mind. Just in case you or
anyone else does, here are the pertinent excerpts:
+++ profile/defaults/mimeTypes.rdf 23 Jan 2003 20:16:09 -0000
@@ -1,11 +1,60 @@
<?xml version="1.0"?>
-<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:NC="http://
home.netscape.com/NC-rdf#">
+<!--
+ This file is used as a persistent data store for helper application
+ information.
- <Description about="urn:mimetypes">
+ The root of the data is the <RDF:Seq about="urn:mimetypes:root"/>. This
+ contains one <RDF:li/> entry per MIME type. Each <RDF:li/> entry corresponds
+ to the "urn:mimetype:major/minor" resource, where "major/minor" is the MIME
+ type. For example, for HTML we would have "urn:mimetype:text/html".
+ Typically, this resource will be in the <RDF:Description/> node which has the
+ corresponding "about" attribute.
+
+ Each "urn:mimetype:major/minor" resource can have the following properties:
+
+ NC:Value - the MIME type string
+ NC:editable - a "true" or "false" depending on whether this entry is
+ editable
+ NC:description - a description of the type ("HTML Document" for text/html)
+ NC:fileExtensions - there will be one of these properties per extension that
+ corresponds to this MIME type, each one having a single
+ extension as its value.
+ NC:handlerProp - the way the type should be handled. This corresponds to a
+ "urn:mimetype:handler:major/minor" resource. Eg, the way
+ HTML is handled would be stored in the
+ "urn:mimetype:handler:text/html" resource
+
+ Each "urn:mimetype:handler:major/minor" resource can have the following
+ properties:
+
+ NC:useSystemDefault - "true" if we should handle per defauly OS setting,
+ "false" or not set otherwise
+ NC:saveToDisk - "true" if the data should be saved to disk, "false" or not
+ set otherwise.
+ (Note - if both of these are false, that means "open in helper app")
+ NC:alwaysAsk - "true" if the user should always be prompted before handling
+ data of this type, false otherwise.
+ NC:externalApplication - the helper application to use for this type. This
+ corresponds to a
+ "urn:mimetype:externalApplication:major/minor"
+ resource
+
+ Each ""urn:mimetype:externalApplication:major/minor" resource can have the
+ following properties:
+
+ NC:path - the path to the application
+ NC:prettyName - the "pretty name" of the application ("Acrobat Reader" for
+ /usr/bin/acroread, eg).
+-->
That reminds me, I need to reopen bug 61408 to ask whether NC:externalApplication
and/or NC:path use input filename %substitution and/or stdin.
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: Future → mozilla1.7alpha
Comment 123•21 years ago
|
||
Actually, none of that is relevant here. This could be done trivially by just
changing a tiny bit of code in nsContentDLF.cpp (to not register as a handler
for the internal view-source MIME type) and setting up a helper for
application/x-view-source.
In any case, please do not set the target milestone of a bug unless you are the
assignee or in a position to control how the assignee spends his or her time.
Undoing the priority and target milestone changes.
Priority: P1 → P3
Target Milestone: mozilla1.7alpha → Future
Comment 124•21 years ago
|
||
Boris, I did realize how easy this is, and in fact I did try to take it, thinking Doron had it as
NEW instead of assigned (see comment 90.) I figured it would be perfect for getting back
into the swing of things since I finally managed to obtain all the big three platforms at my
place and am trying to put a build together on each of them. I've only got weekends for
this, though.
I now realize I need to submit a patch instead.
Thank you for pointing out nsContentDLF.cpp.
Comment 125•21 years ago
|
||
One thing I should make clear. The reason I've not done this yet is that there
is no useful concept of a "text/plain helper app" on Linux. Any proposed patch
needs to address that problem usefully.
Comment 126•21 years ago
|
||
Can't we at least handle the Windows portion for now and make the behavior
disabled on Linux?
Comment 127•21 years ago
|
||
If you are willing to maintain the Windows (and mac, for that matter, since it
would also be easy there) code, be my guest.
Comment 128•21 years ago
|
||
Why would I want to open read-only (=most http) pages in an editor?
Comment 129•21 years ago
|
||
Perhaps you have your personal website stored on your computer and you want to
make changes while you preview it. The files you're viewing don't necessarily
have to be HTTP files - they can be local ones (readable and writable), too.
Comment 130•21 years ago
|
||
> Why would I want to open read-only (=most http) pages in an editor?
Perhaps your editor has copy/paste buffers that you like and you want to extract
code from one page and insert it into another.
Perhaps your editor has hocks in to tools like htmltidy, so you can clean up the
source to make it easier to follow.
Comment 131•21 years ago
|
||
One more note. If people want to open the "live" page in an editor, this
depends on bug 73757
Depends on: 73757
Comment 132•21 years ago
|
||
The particular reason I would find this handy would be being able to use the
same editor I generally use to easily find problems (often with javascript) in
on request server side generated files (as with php) whose html source is not
available unless from view source (often a result from a form submit). When
there is an error on a specific line and I want to get there and see what's
around it, the default source viewer isn't very effective (and will never have
-or even should have- all the useful features an editor can have, such as code
folding, line numbers, go to line, javascript syntax highlighting, regular
expressions based search, caret browsing, easily selecting text with the
keyboard, block selection, etc.). So even if you can't save the file there would
be much use for this.
(Note: I know that some things I mentioned are somehow supported or will be
supported in the future by mozilla, but that is besides the point.)
Comment 133•21 years ago
|
||
>One thing I should make clear. The reason I've not done this yet is that there
>is no useful concept of a "text/plain helper app" on Linux. Any proposed patch
>needs to address that problem usefully.
That seems very odd. :-/
Edit/Preferences/Helper Applications exists in the Linux builds of Mozilla as
well as in the other builds, doesn't it? If not, why not?
If so, there *is* a useful concept of a "text/plain helper app". So I'm not
clear on the point here.
Comment 134•21 years ago
|
||
You can _set_ a text/plain helper app. But there is no predefined one, unlike
on Mac and Windows. The point is, this proposed functionality should just
involve saying "open source externally" and work; it should not require manually
setting a helper to view source with... imo, of course.
Comment 135•21 years ago
|
||
IMHO, the current viewer is pretty good for many purposes as well. IMHO, even
when this is fixed, the current behavour should be the default, at least on Linux.
Comment 136•21 years ago
|
||
Re: comment #134
"open source externally" can *never* be guraneed work on Linux out of the box.
It involves depending on some external editor that may or may not be installed.
View source should use the internal viewer by default and if you want an
external viewer, you should select it yourself.
The closest you can get is xterm -e $EDITOR or $PAGER, but this still depends on
a sane user environment and the presence of xterm (for example, I use rxvt and
have not installed xterm).
Comment 137•21 years ago
|
||
Re: comment #134
I don't care in the least that I will have to set a view-source application 'by
hand' under Linux.
At the moment I *cannot*. I am stuck with Mozilla's IMO useless internal
view-source. (Useless because it can't be used to read the source of a page
which is misdisplaying, due to its reparsing). I want the *option* to view
source with another program.
Just give me the option already.
Comment 138•21 years ago
|
||
Oh, boy. There are actually _two_ possible issues that this bug covers. And
everyone reads it as covering the one they like:
1) Make view-source open in a helper and remove the ability to open it in the
view-source window (or have this be a build-time option).
2) Have both be available, switchable at runtime.
#1 is a no-brainer to implement except then Mozilla MUST be able to detect said
helper automatically (since view-source will not work until there is one). #2
is rather difficult due to the way the content dispatch system works in Mozilla.
Not impossible, and may be done with enough hacking on nsContentDLF.cpp, but
not trivial.
Comment 139•21 years ago
|
||
OK, if comment 138 is the case, how about:
Separate the current mozilla view-source component into a standalone helper app.
Implement case 1 (Make view-source open in a helper), which is supposed to be
trivial. Then ship Mozilla with it defaulting to use the new view-source helper.
This means Mozilla will always be able to find a view-source helper since it
installs its own, but the user to change this to something else if preferred.
I guess I have no idea how difficult it would be to separate out the view-source
part, though.
Comment 140•21 years ago
|
||
Boris, I think case #1 is covered in bug 145021, which was split off from
discussion here. That leaves this bug as case #2, IMO.
Comment 141•21 years ago
|
||
Ah, resummarizing to make that clear.
The viewer could be made a standalone app. It would still need to embed all of
gecko, however. Doable. But might make view-source ridiculously slow to come
up... We won't know for sure till someone does it.
Summary: make view source open in text/plain helper app → make view source optionally open in text/plain helper app
Updated•21 years ago
|
Blocks: input-helper-apps
No longer depends on: input-helper-apps
Comment 142•21 years ago
|
||
I think that one of the reasons why features take years to get implemented is
that a proposal quickly grows into a philosophical discussion of how to reach
Mars and design a sustainable environment up there.
People, it's simple:
-Current behavior:
View source launces the built-in viewer.
-Desired behavior:
Have a pref that can be switched between:
View source using:
[ O ]Internal viewer (default checked)
[ _ ]External application [application pathname/exe name]
Is this so difficult to understand?
Where the application pathname/exe could anything the user enters like:
In windows:
c:\windows\notepad.exe
"d:\some\path\visual slickedit pro.exe"
q.exe
etc
In Linux
/usr/bin/joe
/bin/whatever
Why complicate things with text/plain helper?? The text/plain viewer could be
set to something else. It's the application we use to view the source what we
are talking about. Why mess things by tying one to the other?
Just my $.02
Comment 143•21 years ago
|
||
> Is this so difficult to understand?
No. But it's difficult to implement. Try it.
Assignee: doron → fcassia
Status: ASSIGNED → NEW
Comment 144•21 years ago
|
||
CCing myself and voting as I have a big interest in this bug being fixed too.
My preference would be an option in Preferences to allow selection between
internal source viewer and external viewer, specifiable by the user. Default to
internal, to avoid Mozilla not being able to view page source. If this is very
difficult to implement, it's a shame because it says something about how screwed
up Mozilla's codebase is :-)
I'd like to add an important point: many people are saying that the way to get
an external viewer to view the page is to create a temp file and open it. This
is fine for remote pages, but *DON'T DO THIS FOR LOCAL PAGES*! For local pages,
simply send the existing file to the external viewer. That way, developers can
know that editing a page located on their hard drive will update that page, and
editing a remote page will mean they have to save a new file as the file they're
editing is a temp file.
Comment 145•21 years ago
|
||
Jeremy,
I agree with your concept of having both the internal view-source and allowing
for setting an alternate editor for view-source. However, the only real
purpose for the editor is that is provides nice line numbering, syntax
coloring, searching, code wrapping, etc. But the point of the editor in this
case is not really to edit. The editor has been discussed here because editors
tend to have more functionality than plain text viewers. Let't not complicate
things. Leave view-source as view-source. If you really want to edit a local
file, open the file from the file system. View-source is a snapshot of a
moment in time. For instance, what if I view-source and then have the actual
file open in another editor and make a change? Should the view-source then
change according to the current state or the original file on disk? I'd argue
absolutely not! It should stay exactly the way it was when I opened it.
Jake
Comment 146•21 years ago
|
||
For me, as a website creator, having 'view source' open in an editor where I can
edit the source is infinitely more useful than a 'snapshot in time' of the page.
Ideally the option should be renamed 'view/edit source'... if you want to view
it, associate it with a source viewer, like Mozilla's. If you want to edit it,
you can associate it with an editor. Why on Earth would you need to have a
snapshot in time of sourcecode on your local hard drive? Just save a backup
copy of the file if you want to keep the 'old' version. No, I would indeed like
this menu item to have the ability to open in a text editor. Bear in mind that
the proposed solution would still allow people like you to have that menu option
provide a 'snapshot in time' of the page source, via Mozilla's source viewer; it
could even be set as the default! However it would also allow people like me to
set it to whatever I wish as an external text editor, and how does that
negatively impact you in any way?
Comment 147•21 years ago
|
||
Well, let me put the question back to you. "Why on earth" would you need to
view the source of a local file when you already have it on disk. Just open
the file and you have the source. Why does Mozilla have to step in and open
the file for you? Keeping Mozilla's view-source copy as a snapshot in time
speeds development because then you can just refer quickly back to what you
just did previously without going through any tedium in saving myfile-bak1,
myfil-bak2, myfile-bak3, etc... I don't care to save them permanently. I'd
rather they go away when I close the result of the view-source.
A change in behavior impacts both the Mozilla coders, who have to fork code to
treat local files and remote files differently, and users who expect view-
source to be a snapshot in time, not the actual file you are editing (at least
traditionally). A change in behavior results in more confusion and more code
forking. I'll leave it up to the Mozilla coding team to determine if my code
forking theory is correct or not.
So, I think your idea that your way is totally inocuous to anyone else (so why
should we worry about it) is a false premise.
Jake
Comment 148•21 years ago
|
||
>Why does Mozilla have to step in and open the file for you?
It saves time. Your method involves more steps: open in Moz, open editor, open
file. If Edit Source is available, it becomes: open in Moz, select menu item.
Simpler (in process, not the coding) and faster!
Of course, this is more work for Mozilla coders. You say that's bad? It may be
for the coders, but this isn't about the coders: this is just what some users
want. So what if it's hard to implement or even smacks of Microsoft? Mozilla
isn't just for its developers; it should be targeted to the audience that will
use it. And if that audience wants Edit Source? Give it to them.
P.S.--This discussion probably belongs in MozillaZine's forums and not the area
where developers discuss their work on the bug.
Comment 149•21 years ago
|
||
Oh, where to begin... I'm not going to insult you because that would be rude,
but it'd be nice if you actually thought about what I'd suggested before posting.
> "Why on earth" would you need to
> view the source of a local file when you already have it on disk.
This supports MY argument. The 'view source' should have the option of
resulting in EDITING the file (in a preferred editor), not just viewing it.
> Why does Mozilla have to step in and open
> the file for you?
Because, when I'm viewing a webpage I'm working on, that's MASSIVELY more
convenient than having to open my editor, and navigate to said file manually.
> I don't care to save them permanently. I'd
> rather they go away when I close the result of the view-source.
And if you'd thought before posting, you'd realise that my proposal would keep
this behaviour as default and not inconvenience you.
> A change in behavior impacts both the Mozilla coders, who have to fork code to
> treat local files and remote files differently
Oh, boo hoo. They have to code something? I guess they were expecting to sit
back and have the computer do it all for them. This is a feature request, of
COURSE they have to put some effort into coding it. It's why it's not mandatory
that they code it, but a suggestion.
> and users who expect view-
> source to be a snapshot in time, not the actual file you are editing
And if you'd thought before posting, you'd realise that my proposal would keep
this behaviour as default and not inconvenience them.
> A change in behavior results in more confusion and more code forking.
Perhaps. But, you know, it really isn't THAT difficult. Programming 3D games
is difficult. Recognising when a webpage is local and when it's remote,
enabling a custom application to handle a file's contents is... easier.
Comment 150•21 years ago
|
||
Can you guys move your discussion somewhere else? This bug is long enough as is...
Comment 151•21 years ago
|
||
I don't like the idea of an unsuspecting person being able to modify their local
html files from within viewsource whether being an external application or view
source itself. It should always be a copy. Why not have a way to send the
filename to the clipboard within Mozilla as something other than the "file://"
protocol garbage the operating system doesn't understand so you can click "Save"
in the helper app and then just paste the filename in.
Comment 152•21 years ago
|
||
> I don't like the idea of an unsuspecting person being able to modify their local
> html files from within viewsource
'Unsuspecting'?? "Oh no, I accidentally clicked view source, edited the source
file, and saved it over the existing source." Come on. Why don't we just stop
people from turning on their computers, they might damage them.
Seriously, this argument is bogus, it's incredibly unlikely that anyone would
'accidentally' modify a file this way, there's probably a higher chance that
they'd accidentally delete the file in their file manager.
> Why not have a way to send the
> filename to the clipboard within Mozilla as something other than the "file://"
> protocol garbage the operating system doesn't understand so you can click
> "Save" in the helper app and then just paste the filename in.
Because even I'm having understanding trouble what you're proposing, so it would
be far too complicated. Look, the idea of being able to optionally use a helper
app is CONVENIENCE. It's incredibly convenient for me, as a web designer, to be
able to view the source of a page with 2 clicks and quickly edit it. The idea
of someone 'accidentally' modofying the file is so ridiculous that I think
you're making it up just to support your argument against the helper app idea.
Firstly, it'd be hard to do that accidentally as it is, and secondly, the
DEFAULT behaviour being proposed is to use Mozilla's source viewer. In order to
edit the source, someone would have to first change the source viewer in the
prefs, then right click a page and click view source, then edit the source and
then save the file. That aint gonna happen 'by accident'.
Comment 153•21 years ago
|
||
I think this should be taken to the newsgroups, or mozillazine forums but I'd
just like to respond.
We should let users know both within view source and when going to the helper
application that this is a local file and saving it will modify the original
file with a popup dialog warning that can be disabled from appearing again just
like the security warnings. I don't think "view source" should allow it to be
the original file. Instead, that should be within the Mozilla menu as "Edit
Source" and View Source would just open a copy, while "Edit Source" would do
what you want. View doesn't mean Edit.
The copy/paste thing isn't complicated, but it would be obscure. When you open
up a save dialog, you can type in the whole filename and press enter. Because of
that, if you could copy the filename (text) to the clipboard within Mozilla, you
could just paste it in a "Save" dialog within your favorite text editor. This
raises the issue of how you would tell Mozilla to copy it to the clipboard.
Comment 154•21 years ago
|
||
My 10 votes are used up on more important things. However I'd like to note that
in limited fashion I still use Netscape 3, and view source in it opens the page
in the same text editor I use to maintain my web site.
Comment 155•21 years ago
|
||
Those interested in an unofficial solution can look here: http://mozex.mozdev.org/
Comment 156•21 years ago
|
||
Moses,
Thanks for the reference to mozex. I'm using it now to write into this
textarea in vim. Very neat. However, it is not really that usable since it
lacks keybindings, doesn't override the original keybindings, and has clunky
context menus to access all of its functionality.. I don't think it should
preclude a more "official" solution.
Thanks.
-Chris
Comment 157•21 years ago
|
||
I don't know how many people here are Mozilla users vs. Mozilla Firebird users
(as I am now but wasn't when I heard about this bug), but I figured I'd throw
out the fact that there is a separate bug for this in Mozilla Firebird: bug 172817.
If you use Mozilla Firebird, bug 172817 is what you want to track. It's
targeted for 0.9, which may or may not mean much in reality, but I have no
doubts it will be fixed by 1.0 (guesstimate of ~summer 2004) as it's a big point
for many IE developer/users. Thus, I recommend you cc yourself to that bug and
switch your vote from this bug to that one. In all honesty the Future target
and the helpwanted keyword on this one aren't especially promising for an
imminent fix.
Thanks for reading, and sorry about the bugspam for the Mozilla (not Firebird)
users.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 158•20 years ago
|
||
(In reply to comment #148)
"Mozilla isn't just for its developers; it should be targeted to the audience
that will use it. And if that audience wants Edit Source? Give it to them."
EXACTLY.
If FireFox doesn't offer the useful functionality of the dominate browser
(which is also free), plus more, then why bother to switch to FireFox?
Comment 159•20 years ago
|
||
(In reply to comment #147)
""Why on earth" would you need to view the source of a local file when you
already have it on disk. Just open the file and you have the source."
Jake, when writing HTML pages and you have linked them all together, the next
step is to run it locally as the end user would do to make sure everything
works as you intended, like links, paths to graphics, layout, etc.
While in this debugging stage, it is far more convenient to right click, view
source, and edit it if needed directly from the area you are looking at,
instead of searching for the right file, which could be time consuming if you
have a large website.
It is offered in IE, which dominates the browser market.
If you want to make a competitor to something, the worse thing to do is leave
out useful functionality.
Comment 160•20 years ago
|
||
Editing a file on disk would be generally useless for me (except when developing
the templates), since I don't use static pages but CGI w/ templates. Yet it is
nice to be able to sometimes add a few words and then copy/paste that into my
template.
Then again, probably 90% of people writing pages write static pages (but the
ones who write the most pages write CGI).
Updated•19 years ago
|
No longer blocks: input-helper-apps
Comment 161•19 years ago
|
||
I don't see the importance of being able to edit the actual file you're looking at. As I understand it, when you view the source of any page in IE what you actually get is a copy of the file that's saved in a temporary directory. That behavior seems perfectly adequate; what people seem to want mainly is the ability to /view/ a file in a better app (with syntax highlighting, reformatting, whatever), rather than in-place editing.
Voting for this bug.
Comment 162•19 years ago
|
||
When you view a *local* page in IE you actually get the real file, not a copy. This is very useful for developers who have instant access to a file on disk from his browser.
Comment 163•19 years ago
|
||
ViewSourceWith extension does this quite well. Is there a way to implement all its functionality in Firefox?
Comment 164•17 years ago
|
||
ViewSourceWith extension works fine in SeaMonkey 1.1.3
I'm voting for this. I seem to recall Netscape Composer had a "Edit with ..." menu option. ViewSourceWith opens CSS and JavaScript files as well, but not "Selection source".
Comment 166•17 years ago
|
||
From what Simon stated on IRC today, SeaMonkey trunk has most things needed for supporting this due to using the toolkit view source, but some navigator.js magic is still missing.
Assignee | ||
Comment 167•17 years ago
|
||
Calls to viewutils.js copy-pasted from browser.js
Assignee: fcassia → smontagu
Status: NEW → ASSIGNED
Attachment #296387 -
Flags: superreview?
Attachment #296387 -
Flags: review?
Assignee | ||
Updated•17 years ago
|
Attachment #296387 -
Flags: superreview?(neil)
Attachment #296387 -
Flags: superreview?
Attachment #296387 -
Flags: review?(neil)
Attachment #296387 -
Flags: review?
Comment 168•17 years ago
|
||
Eww, that invokes the sucky toolkit view source window (OK, so it does print preview which we don't so it's almost sucky).
Comment 169•17 years ago
|
||
I want to add a couple observations, being a heavy user of Greasemonkey (http://xsidebar.mozdev.org/modifiedmisc.html#greasemonkey), and also of Stylish (http://xsidebar.mozdev.org/modifiedmisc.html#stylish).
I do have the ViewSourceWith extension and I sometimes use it to fix this bug, but I don't have much use for these tools in editing my own web sites. These tools are becoming more popular for editing other people's sites.
Opening external CSS and JS files without ViewSourceWith is nearly impossible - you have to View Source, search for the link and script elements, then most often you have to piece together the URL, paste that into Location then either view it or save it... etc. With ViewSourceWith you can do this in two clicks (from the context menu). Oh you can get the links from View Page Info - Links, which is easy if the list isn't too long.
Viewing original page source is no problem, I have the choice of the Mozilla view source or ViewSourceWith options or Composer (which also has the ViewSourceWith menu), however at times I miss having the "Edit with..." option in Mozilla's View source - I will usually copy-paste the code.
The biggest annoyance is View Selection Source. I finally figured out I can get the entire page in WYSIWYG-source by Select-All then View Selection Source, or of course a fragment by selection. This is important for two reasons - large pages are hard to search through (for elements you want to remove, for example), and the DOM source is sometimes different (for example when trying to match inline style attributes).
When you select an area you want to copy, View Selection Source almost never selects the elements you need to copy, and it can be extremely hard to reselect the proper area, and if you copy everything you end up losing your place.
Some option of opening the selection in an external editor, or at least an "Edit with..." option I think is something to consider. More and more people are using these tools every day, even if they aren't using SeaMonkey.
Updated•16 years ago
|
QA Contact: chrispetersen → doronr
Target Milestone: Future → seamonkey2.0alpha
Comment 170•15 years ago
|
||
This bug is open but targeted for seamonkey2.0a1, which has been released a long time ago. Please set the target milestone to an appropriate value, "---" if it has no specific target.
Comment 171•15 years ago
|
||
smontagu, do you still want to work on this?
(BTW, regarding Neil's comment # 168, I think we should eliminate the duplication of view source windows in SeaMonkey anyhow and achieve anything we want special in SeaMonkey with an overlay on the toolkit one.)
Target Milestone: seamonkey2.0a1 → ---
Assignee | ||
Comment 172•15 years ago
|
||
This is not really on my radar any more, no.
Assignee: smontagu → nobody
Updated•15 years ago
|
Status: ASSIGNED → NEW
QA Contact: doronr → view-source
Comment 173•15 years ago
|
||
Comment on attachment 296387 [details] [diff] [review]
Patch
>- BrowserViewSourceOfURL(webNav.currentURI.spec, docCharset, pageCookie);
Nit: You also need to remove the declaration and initialization of docCharset.
>+ BrowserViewSourceOfURL(webNav.currentURI.spec, pageCookie, aDocument);
Bug 331940 added a convenience method that completely replaces this call :-)
Don't forget to update the other call, of course! sr=me with these fixed.
>+ var utils = window.top.gViewSourceUtils;
Unnecessary. Just call gViewSourceUtils directly.
>+ <script type="application/x-javascript" src="chrome://global/content/viewSourceUtils.js"/>
Nit: This belongs in the generic utility section.
Attachment #296387 -
Flags: superreview?(neil)
Attachment #296387 -
Flags: superreview+
Attachment #296387 -
Flags: review?(neil)
Attachment #296387 -
Flags: review+
Assignee | ||
Comment 174•15 years ago
|
||
Transferring r+sr.
I don't have a working build environment for suite these days. KaiRo, would you like to test that this still works and drive it in?
Attachment #296387 -
Attachment is obsolete: true
Attachment #448545 -
Flags: superreview+
Attachment #448545 -
Flags: review+
Comment 175•15 years ago
|
||
(In reply to comment #174)
> I don't have a working build environment for suite these days. KaiRo, would you
> like to test that this still works and drive it in?
if it's OK with you to wait a few weeks, then possibly. I have a real lot of stuff in my TODO list, and this wouldn't have any significant priority for me.
Comment 176•15 years ago
|
||
pushed to comm-central:
http://hg.mozilla.org/comm-central/rev/71e60f59c680
Minor typo, fixed locally.
Error: window.top.gViewSourceUtils.viewsource is not a function
Source file: chrome://navigator/content/navigator.js
Line: 1479
Interdiff:
--- C:/T1/patches/viewsource/bug8589.2.diff Fri Jun 04 17:39:24 2010
+++ C:/T1/patches/viewsource/bug8589.3.diff Fri Jun 04 18:17:57 2010
@@ -11,7 +11,7 @@
if (url.match(/^view-source:/)) {
- BrowserViewSourceOfURL(url.replace(/^view-source:/, ""), null, null);
-+ window.top.gViewSourceUtils.viewsource(url.replace(/^view-source:/, ""),
++ window.top.gViewSourceUtils.viewSource(url.replace(/^view-source:/, ""),
+ null, null);
} else {
// Check the pressed modifiers: (also see bug 97123)
@@ -64,7 +64,7 @@
- "_blank",
- "all,dialog=no",
- url, charset, pageCookie);
-+ window.top.gViewSourceUtils.viewsource(webNav.currentURI.spec,
++ window.top.gViewSourceUtils.viewSource(webNav.currentURI.spec,
+ pageCookie, aDocument);
}
Comment 177•15 years ago
|
||
Tested with both internal view source and external view source editor.
Thank you simon for your patch!
Funny view source error but don't think it's caused by this patch:
Error: this.webShell is null
Source file: chrome://global/content/viewSourceUtils.js
Line: 182
Assignee: nobody → smontagu
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 178•15 years ago
|
||
(In reply to comment #173)
>(From update of attachment 296387 [details] [diff] [review])
>>+ var utils = window.top.gViewSourceUtils;
>Unnecessary. Just call gViewSourceUtils directly.
When I said directly, I meant "not via a useless window.top. prefix" ...
Comment 179•15 years ago
|
||
(which as it happens would have avoided having to wrap those lines)
Comment 180•15 years ago
|
||
>>(From update of attachment 296387 [details] [diff] [review] [details])
>>>+ var utils = window.top.gViewSourceUtils;
>>Unnecessary. Just call gViewSourceUtils directly.
> When I said directly, I meant "not via a useless window.top. prefix" ...
> (which as it happens would have avoided having to wrap those lines)
Fixed.
Pushed followup patch to comm-central
http://hg.mozilla.org/comm-central/rev/fd4b1728dcae
Updated•14 years ago
|
Component: View Source → General
Product: Core Graveyard → SeaMonkey
QA Contact: view-source → general
Target Milestone: --- → seamonkey2.1a2
You need to log in
before you can comment on or make changes to this bug.
Description
•