Closed Bug 74862 Opened 23 years ago Closed 14 years ago

Ability to save highlighted source in view-source

Categories

(Core Graveyard :: View Source, enhancement)

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

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: bischoff, Unassigned)

References

(
URL
)

Details

Attachments

(4 files)

This is the resulting file, going through your process.
36.95 KB, text/html
Details
very raw-around-the-edges patch
2.56 KB, patch
Details | Diff | Splinter Review
Cleaned-up patch with complete UI included
6.18 KB, patch
Details | Diff | Splinter Review
patch that disables the menuitem as needed
6.57 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8.1)
BuildID:    2001040504

Mozilla makes some pretty syntax hilighting in View Source, and it would be
great if the HTML code used to create such coloring were available (that is, the
auto-generated HTML *in* the View Source window). This would be handy, for
instance, when writing HTML or JavaScript tutorials for the web, as the author's
code could be converted-to-colorized quite easily in this manner.

Reproducible: Always
Steps to Reproduce:
1. Right click on any url
2. Choose "View Page Source"
3. In the View Source window, right-click again
4. Notice that there is no context menu, which of course doesn't include "View
Source"

Actual Results:  View Source window has no context menu, and this doesn't
include a " View Source" option.

Expected Results:  "View Source" should be an option within View Source.

This could be related to bug 39389.
Windows 2000,build 2001040420
You can select the source or part of the source en copy it to the clipboard 
(Ctrl-c or ctrl-insert). When pasting in an editor that understands the HTML 
clipboard format it is pasted as highlighted source. Tested this on Word 2000 
and it works. So this would probably be a duplicate or a depend on bug 63026.
Could you give me an example of such an editor on Win2000? Also, just to make
sure we're talking about the same thing, I'll elaborate on the feature request. 

If I choose View Source on this very page, I get a window with the source code,
with syntax coloring.

Among other things, the <html> and <head> tags are purple, strings are blue, and
"nbsp" is orange. If I were to choose View Source *on* the "View Source" window,
I'd like to see html code such as the following:

&lt;<font color="purple">html</font>&gt;&lt;<font color="purple">head</font>&gt;
[...]
&lt;<font color="purple">body</font> <b>BGCOLOR</b>=<font
color="blue">"#FFFFFF"</font> <b>TEXT</b>=<font color="blue">"#000000"</font>

(And so on..) Does that make sense? That is, I'd like to see the *actual HTML*
that makes the coloring and syntax hilighting within the View Source window.
I understand what you mean. I tried this on Frontpage. It seems the Mozilla 
editor also supports this, pasting the highlighted source in Composer set 
to 'normal view' mode , it is pasted including the highlighting code. Switch 
to'<html> source' to see the source. 
Copy the highlighted source <td VALIGN="TOP"> in Composer gives:

<pre style="font-family: -moz-fixed; font-weight: normal; color: black; padding-
top: 4px; margin-left: 4px; ">&lt;<span style="color: purple; font-weight: 
bold; ">td<span style="color: black; font-weight: bold; "> VALIGN</span>=<span 
style="color: blue; font-weight: normal; ">"TOP"</span></span>&gt;</pre>
I went through the process that you describe with Composer (see attachement).
However, it doesn't quite look the same, especially in the line-breaks department.

So, nonetheless, your method is an almost-workaround (and gives a very close
approximation of what I'd like to see in View-Source-of-View-Source). However,
since there's still the discrepancy, I'd like to see this feature fully implemented.
confirming rfe. ->bill?
Assignee: ben → law
Status: UNCONFIRMED → NEW
Ever confirmed: true
I would think that's merely composer shreading the html and not a flaw in this 
feature which seems to have already worked by the type you reported it.
doron, is it easy to make it so we can save the content of the view source 
window?  Would that fulfill this RFE?
I believe when my menu path lands, that using the "edit page" command will
launch composer with the sourcecode with highligthing.  I'll check it out later.

As for a viewsource window for the viewsource window, should be easy.
Actually... a view source of view source may not be so easy.

This is how view source works.  A webshell has two modes.  In normal mode it 
just shows the document.  In View Source mode it shows the source.  So for view 
source all we do is take a webshell, put it in View Source mode and load the URI 
 of the page we are viewing source for.

The textual representation of the view source window is not stored anywhere -- 
the document is constructed directly in the parser, so it just exists as a parse 
tree...
right, was not thinking when I wrote that.  question is, how usefull would this
feature actually be?
As a professional Web Engineeer, this would be highly useful to me. As I often
write HTML and/or JavaScript tutorials for my co-workers (and others), I
frequently have to show example source code in a webpage. If I were able to use
View-Source-of-View-Source, it would greatly ease my task of color coding my
code (and changing ">" to "&gt;", etc).
this is a very nice feature to have

whenever menus and context menus for view source window will be implemented,
maybe just put 2 different types of save in them?
File -> Save as text
File -> Save as HTML

this bug depends on bug 39389 and bug 63026
Depends on: 39389, 63026
IMO the default "save as" option in View Source (if there is a "save as" 
option) should be to save the original source.
As long as we're adding dependencies...  Adding dependency on bug 66334 -- until
that arch change is in, doing this is a waste of effort.  Once that's in we can
figure out how to do this properly.
Depends on: 66334
Have a look at the teaser bug 78619.
Got the menu item there. Ah, only if it would work... ;o)

This issue also raises a question of infinite regression of viewsource.
That is: ViewSource -> ViewSource of ViewSource -> ViewSource of ViewSource of
ViewSource -> and so on.

Bug 78619 will most likely get fixed by disabling the "view source" options 
inside view source, is my guess.

Without some major rearchitecting infinite recursion will not happen.  That 
rearchitecting would take place in the parser.

The last rewrite of view source restored the ability to dump the source of view 
source to a file as it's being rendered on the screen.  This is currently inside 
a debug #ifdef, but the thought was that we could change that code slightly and 
allow a "Save as colored source" menu option to view source.  Then you could open 
the resulting HTML in your favorite text editor.  Would that work?

In either case, this is parser work.  Over to parser.
Assignee: law → harishd
Component: XP Apps: GUI Features → Parser
QA Contact: sairuh → bsharma
Yeah, as long as there's some way to capture the source that's generated within
View-Source, then that's a plus :). 

As for the "infinite recursion", why is that a bad thing? It's not like it's
uncontrolled infinite recursion -- the user has to hit "View Source" each time
to progress along the path of View-Source-of-View-Source-of-View-Source.
I'm not saying it's a bad thing.  I am just saying that the entire way we do view 
source would need a complete rewrite from scratch with a totally different 
approach of some sort in order to support that sort of recursion.  Unless we can 
come up with a good reason to do it (coolness factor is not good enough, imo) 
it's probably not worth the effort.

Taking this bug to implement the save-to-file approach.  Alex, let me know if I 
misunderstood you and that would not do what you're asking for.

Doron, you want to handle the menu side of this?
Assignee: harishd → bzbarsky
OS: Windows 2000 → All
Priority: -- → P3
Target Milestone: --- → mozilla0.9.2
Status: NEW → ASSIGNED
Boris: As a Web Engineer, I often write HTML and JavaScript tutorials, both for
my co-workers and others. So, I often need to include example code in these web
based tutorials -- and, it'd be really convenient if I could capture Mozilla's
output instead of having to color-code my code on my own.

So, either solution (View-Source-of-View-Source-of-View-Source or
Save-View-Source) would suit my needs. Though the former does have a certain
coolness factor to it ;), I can understand if that's too extensive.
I have this pretty much working.  But to do it right I have to grab the
stylesheet from the DOM.  That works if I cheat, but depends on bug 79818 if I
do it right.  So adding dependency.
Depends on: 79818
OK.  Attaching a patch.  This is just the backend function -- the menuitem/key
shortcut/whatever still need to be added to call it.

It has one other issue -- "haha" is not a good title for the filepicker in this
case.  We want to decide on something nice in a stringbundle and then grab it
from there, most likely.
Reviews please?  doron?  blake?
Keywords: mozilla0.9.2, patch, review
Notice that the patch adds a file
(xpfe/browser/resources/locale/en-US/viewSource.properties).  So if you have
trouble applying that may be why.
tree has closed for 0.9.2.  Pushing out to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Soo... it's been 3 weeks.  Anyone care to actually review that last patch? :)
Keywords: mozilla0.9.2 → mozilla0.9.3
patch looks great, just one thing - what if syntax highlighting is turned off?  
Perhaps disable the context menuitem if that pref is set off?
r=doron
I am not familiar with the implementation of the View Source window, but it 
occurs to me that the result document could be dynamically generated via 
XSLT.

This would leverage existing code, and allow for further application of the 
stylesheet to generated views.  Not only that, it would permit user-defined 
view-source style by manipulation of the associated style sheet.

This is probably too high risk/low reward for an RFE, but it seems like the 
Right Thing.
Resummarizing to make it clear what the bug is about at the moment.

Talked to blake, who isn't sure this is a good idea to have in the UI at all.

mpt?  What do you think?  I can provide a screenshot if you'd like.
Summary: [RFE] View-Source of View-Source → [RFE] Ability to save highlighted source in view-source
pushing out pending mpt's comments.
Target Milestone: mozilla0.9.3 → mozilla0.9.5
Ooh, this is truly bizarre.

`File' > `Save As ...' from the View Source window should do exactly the same 
thing as `File' > `Save As ...' from the browser window -- that is, save the 
original HTML, not some entitied-and-colored-up-the-wazoo HTML rendering of the 
source. If it didn't save the original HTML, people would start filing that as 
a bug. (If `View Source' was available for the View Source window at all, that 
would be a bug too. `View Source' should change to `View Page' in a View Source 
window, to do the opposite of what `View Source' does in a browser window.)

That the coloring is done using HTML formatting is an implementation detail 
which should be completely transparent to the user. Hmmm ... file format 
transparent to the user ... That reminds me of something. What? Oh, yes. The 
system clipboard! So ... When text is copied from the View Source window and 
pasted into an app which understands colored text (such as Composer, or MS 
Word), the coloring should get pasted too. As Timeless said, any bugs in that 
copy/paste process should be filed, but this bug looks very much like a 
wontfix.
Matthew's comments made me think of this in a new way.

What concerns me about this feature is that  it will force Mozilla to downgrade
a Strict XHTML page.  That is, assuming that the output of this function is
*just* (X)HTML, the color information has to be in the generated (X)HTML, not in
a stylesheet.  IIRC, this means the (X)HTML will no longer validate against the
Strict DTD, whereas the source document would have.  While this could be handled
by generating both (X)HTML and the stylesheet, it makes it a little dirtier at
the same time.
This also raises the question of the "appropriate" representation of the color
information.  Should it be HTML, Transitional XHTML, Strict XHTML?  While a
decision may not be necessary for cut-and-paste because of flavors, it may be
elsewhere.  If I had to choose, I'd pick Strict XHTML, but that gives the
aforementioned two document problem.  Other "solutions" suffer similar pitfalls,
either forcing a downgrade somewhere, or relegating Mozilla to generating
primitive HTML, which also seems dirty.
Just to address some comments:

> When text is copied from the View Source window and pasted into an app which
> understands colored text (such as Composer, or MS Word), the coloring should
> get pasted too.

Ooh....  Fun.  Is there a cross-platform way of representing color information
in the clipboard?  The old setup we had (where color was done with style
attributes on spans) would at least keep color when copied as HTML.  The new
setup (with color done as classes and a stylesheet) will _not_ keep the colors
when copied as HTML, of course.  The wonders of separating content and
presentation (and I'm not being facetious, I mean that).  One can of course add
a stylesheet to the resulting document to highlight the code -- the class names
will still be there.

> `File' > `Save As ...' from the View Source window should do exactly the same
> thing as `File' > `Save As ...' from the browser window

With my patch, it still does.  All that's changed is that in View Source another
option is added -- "Save Highlighted Source"

mpt, is this still wontfix in your opinion given my description of the problems
involved in getting the color information into copied text and the clarification
about what's really going on with the menus?

>  That is, assuming that the output of this function is *just* (X)HTML

If you read the patch, you will see that it is not.  My code actually generates
strict XHTML with a <style> element in the head which contains all the style
information that's in an external stylesheet in viewsource (viewsource.css).

The code currently does not output a doctype, so the resulting HTML is not
strict.  But I can easily add a 4.01 Strict doctype and it would validate.  I
could do strict XHTML just as easily, of course.  The documents created by the
view source parser validate against that too.....
Boris,

I didn't get a chance to read your patch, don't know if I could anyway.  Since
you use <STYLE>, though, how are you gonna markup HTML that doesn't recognize
that tag?  That was partly my point.  I'm probably the only one that sees that
as an issue, but I get enough problems with MS software generating invalid HTML,
I don't want Mozilla doing the same.
> Since you use <STYLE>, though, how are you gonna markup HTML that doesn't
> recognize that tag?

Perhaps it's not clear how this process works.  I save an HTML 4.01 document
with a <style> tag.  The markup provides highlighting.  The text is the
contents  of the original document (escaped as necessary).  For example, for
"<html></html>" (a very small document, indeed) I would save:

<!doctype whatever>
<html>
<head><style> .... </style></head>
<body>
&lt;<span class="start-tag">html&gt;&lt;/<span class="end-tag">html&gt;
</body>
</html>

Since <style> is in _my_ document and my document is HTML 4, it's definitely
recognized.
Sorry I don't know C++ well enough to figure out the patch. How does it end
lines? Like <html></html> gets output as:

<!doctype whatever>
<html>
<head><style> .... </style></head>
<body>
&lt;<span class="start-tag">html&gt;&lt;/<span class="end-tag">html&gt;
</body>
</html>

Instead of
'<html></html>'
if the starting markup is
'<html>
</html>'
then what would go between '&lt;<span class="start-tag">html&gt;' and
'&lt;/<span class="end-tag">html&gt;' to make the '</html>' be on the next line?
Is it <br> or <br/> or something else? Reading through the bug, I see that Boris
first the patch generates XHTML (<br/>) and later it's HTML 4 (<br>). So if you
insert a !DOCTYPE (recommended) then make sure it matches the kind of <br> you
use. If you don't use <br> then ignore all the above.

Another point: it looks like when syntax highlighting is disabled, the option to
save the (X)HTML from the view source window is also disabled. (again I don't
know enough C++ to tell for sure) It would still be a nice feature to be able to
save the escaped markup, even if it's not color-coded. Just a thought...
> if the starting markup is
> '<html>
> </html>'

I have to apologize.  I forgot the <pre> tags in my description of the output I
create.  So to get a newline, I output... a newline.  Thus in the
'<html>\n</html>' case we would have:

<!doctype whatever>
<html>
<head><style> .... </style></head>
<body>
<pre>
&lt;<span class="start-tag">html&gt;
&lt;/<span class="end-tag">html&gt;
</pre>
</body>
</html>

> it looks like when syntax highlighting is disabled, the option to
> save the (X)HTML from the view source window is also disabled.

Correct.  This code is in javascript, by the way, not C++....

> It would still be a nice feature to be able to save the escaped markup

Escaping the markup is a trivial operation that involves 3 regular expressions
(the ones I apply).  It hardly seems worth opening a page in a browser to get
its escaped markup.
QA Contact: bsharma → moied
Futuring.  The UI people mislike this...
Target Milestone: mozilla0.9.5 → Future
bz: Could you elaborate on UI's reasoning? This functionality would be very
helpful to web developers such as myself. Would a prefs.js setting make it more
acceptable to them?
See the comment by "Matthew Thomas (mpt)" on 2001-08-26 09:38.  He's the UI
module owner...


bz: Thanks for pointing that out. I can address those concerns.

As for "Save As", I wouldn't recommend that name either (as users probably would
be confused). But, perhaps "Save Highlighted Source" (next to the usual "Save
As") might work.

mpt also mentioned copying to the clipboard, but I think that's only a kludge,
as Linux (and possibly Mac) don't offer such clipboard functionality.
> as Linux (and possibly Mac) don't offer such clipboard functionality.

That's actually not true.  You can put things in the X clipboard in the
text/html flavor and if the app being pasted into is not dumb, it will get the
HTML.  Most apps are dumb, however.  Mozilla itself is not, I must note.

And the menu item I added _is_ called "Save Highlighted Source"!

mpt?  Comments?  You never responded to my comments on this earlier...
Just to clarify, I'm not the UI module owner. That's Ben Goodger for the 
browser, Seth Spitzer for mail/news, and I-don't-know-who for the editor.

Anyway. If you're convinced this is useful, then sure, implement it -- but only 
after Ben Goodger finishes what he's working on right now for saving complete 
Web pages with images etc. Part of that work is adding a file type option menu 
to the Save filepicker, and `Highlighted Source Code' (or something like that) 
could be one of the options in that menu when a page is saved from the source 
window. Any other UI for this would be weird.
Priority: P3 → P5
The filepicker-based solution is about as inflexible and hard-to-extend as
possible, at the moment.  Yay.

Reassigning various UI bugs to default owners.
Assignee: bzbarsky → doron
Status: ASSIGNED → NEW
Component: Parser → ViewSource
QA Contact: moied → pmac
I've found a near workaround that is truly wonderful in its unnecessary complexity.
In the page I wish to get formatted source for, I execute

javascript:window.open("view-source:data:text/html,<html>\n" +
document.documentElement.innerHTML + "\n</html>"); void 0;

either by typing it in the address bar, or by selecting a bookmarklet with the
above as its address.
This brings up a standard Mozilla window, displaying the syntax-highlighted
source of the first window.
In the new window, I then execute

javascript:window.open("data:text/html,<html>\n" +
document.documentElement.innerHTML + "\n</html>"); void 0;

which brings up a third window, superficially identical to the second window but
whose actual contents are the HTML needed to generate the third window.
I can then select File->Save Page As..., and by choosing "Web page, complete"
from the filepicker dropdown I get a HTML file and accompanying stylesheet
'viewsource.css' which together will suffice to display the Mozilla-generated
syntax highlighted source in any browser.

The one problem with the above is that it takes ages to save the HTML file,
perhaps due to some type of recursion - 55 seconds to save the formatted source
of www.mozilla.org/start/, with near 100% CPU utilisation during that time; my
specs are: build 2002092108, WinXP Pro, Athlon XP 1800+, 768MB PC133 SDRAM. 

If, however, at the second step I instead execute

javascript:window.open("view-source:data:text/html,<html>\n" +
document.documentElement.innerHTML + "\n</html>"); void 0;

I get a "view-source of view-source" which I can then copy into a plain-text
editor (Notepad) and save as a HTML file; although this does not suffer from the
excessive performance issues of the first approach, there is a slight problem:
the copied HTML file gets its style information from

<link rel="stylesheet" type="text/css" href="resource:/res/viewsource.css">

and so will only work in Mozilla and related browsers, unless I either provide
the viewsource.css myself (by saving resource:/res/viewsource.css and altering
the above line to reference the saved copy) or remove the above line and insert
the contents of resource:/res/viewsource.css inside a <style
type="text/css">...</style> element.

Finally, can I just say that in my opinion, the people most likely to to use
view-source will in general be hackers and developers, who will be perfectly
willing to put up with 'weird' UI for the sake of the feature; can't we just add
the "Save Formatted Source" menu item and file a bug on the UI of it?
Update: the performance lag with the first method has disappeared (my downloads
list had become corrupted). The first method is now the better workaround.
Summary: [RFE] Ability to save highlighted source in view-source → Ability to save highlighted source in view-source
Product: Browser → Seamonkey
Assignee: doronr → mrbkap
Priority: P5 → --
QA Contact: pmac → doronr
Target Milestone: Future → ---
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
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
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
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
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
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
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.

Attachment

General

Creator:
Created:
Updated:
Size: