Closed Bug 94344 Opened 23 years ago Closed 14 years ago

XP Telnet client

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: raccettura, Unassigned)

References

Details

(Keywords: helpwanted)

I for one (and I am sure there are many others) would love to see a telnet app
available in Mozilla right below IRC.  I think there are many who would benefit,
and considering that many Telnet apps are open source, there is something to
work with.  Mozilla is great because it is so complete (web, search, email, page
creation, irc) why not telnet?
Confirming RFE.

All/All?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Telnet → [RFE] Telnet
Not a bad idea, and definitely one for all platforms as well.
Hardware: Macintosh → All
I would love to see this, but I wouldn't use it unless it gave me parity with
packages I have used before.  Specific features I would look for are the following:

1) terminal emulation (vt100/vt102/etc.,arrows keys,ANSI color)
2) configurable backscroll buffer
3) ssh support
4) client scripting

It would also be conveniet if this client could be embedded into a web page, for
demonstration purposes, but I have no idea how this would be done.  Perhaps
extending the anchor tag with a height and width specifying window size:

<A HREF="telnet:somesite.org" height="400" width="600" />

I don't really like that idea, but throwing it out there in hopes that it will
produce a better idea...
How about SSH support?

As for:
"<A HREF="telnet:somesite.org" height="400" width="600" />"

it's not a bad idea actually.... right now in most browsers you can type in 
"telnet:somesite.org" and that opens a telnet window... this way you can choose 
the size.


How about an imbed tag or something that would let you imbed a telnet window into 
a web page?

Just like this comments box is, just with telnet in the box, and using hidden 
values, the web master writing the page could specify options such as:
TextColor="FFFFF"
BGCOLOR="00000"
Server="somesite.org"

That way it could even be imbeded into a web site... good for older sites  like 
the library of congress who use telnet to access some information.
Here are a few open source Mac Telnet programs that someone can take a look at.  
I don't know how much good they may be.

http://www.mactelnet.com/project/
http://www.sourceforge.net/projects/macssh/


I think it would be an awesome feature.  Telnet is very much still alive and 
used.  If Mozilla supported Telnet and SSH that would be great.  Imagine having a 
good telnet client, mail app, web browser, WYSIWYG HTML editor in one 
application!
Let's not get carried away please!  There is no height and width attribute for
the anchor element in the HTML 4 standards, so the previously mentioned
extension will not happen, unless the W3C is convinced to implement those as
part of the standard, and I don't foresee that happening with XHTML/CSS in the
future.

There will be no embedding into a webpage unless someone volunteers to write a
Java app (I think there might already be a few).  Embedding a chromed telnet
client into a page makes no sense.  It's like embedding a chromed mail client or
something.  This RFE is for a standalone XP app much like ChatZilla as far as I
can tell.

Related are: bug 33282, bug 37637, and their dependencies.
http://protozilla.mozdev.org/ is another good reference.

Over to Networking and cc:benc -- what do you want to do with this?
Component: XP Utilities → Networking
Christopher,

I agree with your comments about the anchor tag.  I know it isn't part of the
standard, and that's why I said it was a bad idea.  Not to mention the amount of
rework it would cause...  My other comments are more realistic, however.

I did, however, want to convey the idea of the embedded telnet window.  HTML is
not the right place for it, and I don't know where the right place is, but I'm
confident somebody here does.

The anchor tag choice wasn't completely arbitrary, however.  I needed to specify
the URI, and in principle, the behavior.  Selecting this "tag" would connect to
the URI, analogous to the anchor tag.

I should have been more precise from the start.
If there is to be any embedding going on, it will be from a Java applet or
possibly a plugin -- not through Mozilla.  We run the risk of starting another
blink vs. marquee or document.layers vs. document.all fight if we have our own
special embedded browser "feature."  A search on google for "telnet java client"
will find a TON of nifty Java apps that you can use for this purpose.

The RFE is fine the way it is now.  I am changing the summary to make it more
obvious as to what is requested.  Anything else is a *separate RFE*.  The
newsgroups would be the best place to discuss this further.  This bug is already
way too long and nothing has been accomplished.
Summary: [RFE] Telnet → [RFE] XP Telnet client
telnet URLs already have a specified format.

I'm parking this under XP-GUI, for now.

Lets do the design discussion in the newsgroup. Probably discussing this in 
Netlib, and posting a notice of discussion (NOT a cross post) to .general and 
any XP groups would be best.
Assignee: scc → blake
Component: Networking → XP Apps: GUI Features
QA Contact: scc → sairuh
For additional info on ssh, see bug 39714.
Embedding a telnet url into a html page is no problem. We can use Chatzilla as
an example. Just put an irc-url like irc://irc.mozilla.org/ into a page, click
on it and chatzilla is coming up and connecting.

With protozilla installed clicking on a telnet link brings up the native telnet
application already installed.

But I also would like a XP telnet client. It could be something combining a
telnet protocol library inside necko, a client-look similar to chatzilla and an
interactive component that works much like xmlterm.
I know. The telnet URL examples were in the wrong format.

I'm all for having a diversity of modules in mozilla, although I'd comment that
TELNET is pretty complicated once you start adding terminal mode support.

I'll leave the rest to the coders...
Reformulated the embedding issue into bug 95329, with a somewhat cleaner
presentation than before.  We've polluted this bug enough...
Is there a status on this?  Has coder actually taken up the idea?  Or is it just
that an idea?
--> nobody unless someone else is interested (?)
Assignee: blakeross → nobody
Just out of curiosity, has anyone decided to take this up?  Or is this idea good 
as dead?
Robert: Judging by the assignment to "nobody@mozilla.org", my guess would be the
latter.
> Just out of curiosity, has anyone decided to take this up? 
> Or is this idea good 
> as dead?

Well, that's the great thing about open source.. no idea is ever /really/ 
dead.  If you want this feature, you can write it, if nobody else is doing it.

Now, having said that... I'm really interested in this.  I was planning to mail 
the other people who had posted in this bug so far, and see what was going on 
with it.  If nobody is working on it, I might be interested in getting 
something started.

Robert, would you be interested in helping to implement this, if there isn't 
anybody working on it already?

I am no programmer, but I am more than willing to spend time consulting and 
giving ideas on what it should be.
> I am no programmer, but I am more than willing to spend time consulting and 
> giving ideas on what it should be.

Cool. I am a programmer, but I'm new to a lot of the Mozilla technologies, like 
XPCOM and XUL.  So, if no experienced mozilla coders don't jump in and offer to 
help, this might take a while.  I am definitely willing to contribute some time 
to this, either way.

Given the nature of this conversation, I'm thinking it should probably be taken 
to one of the newsgroups at this point.  I'm not sure exactly which one would 
be appropriate though. Any mozilla.org'ers care to comment?  Is there a 
newsgroup which would be appropriate to carry out conversation related to this?
netscape.public.mozilla.netlib for networking/protocol stuff
netscape.public.mozilla.xpfe for ui-technology related stuff

might be good starting places ...
Thanks, Andreas.  I see that some discussion of this started in netlib, back in 
August, but seemed to die away pretty quickly.  Are you aware of any work which 
is being done on this?  I am interested in working on it, but don't want to 
duplicate any work which is already being done...
From what I know, not much has been done.  Here was my idea:

Keep the client very similar to the IRC client, so that it keeps a universal 
appearance.  

There are a few clients which may be worth taking a look at:

http://macssh.com/
http://www.mactelnet.com/

Both are Mac Clients, but they are really well done... Great features, decent UI.  
I think someone should take a look at the source from those, maybe we can base it 
off of them.  MacSSH has a great start as far as features go, and MacTelnet seems 
to have some more modern updated features (great interface)  So maybe that is a 
good place to start.  I know they are only Mac, but since this has to be written 
for Mozilla anyway.  They are good places to start and maybe even pull some code.  
There isn't really much use in reinventing the wheel.
No, I'm not aware of anything currently done in this area.
Can we assign this to: sprhodes@lycos.com?  If I am able to do that (which I 
don't think I am) I don't have a clue how.  Lets give him a try at starting this, 
he said he is willing to.
Assigned to: sprhodes@lycos.com
Assignee: nobody → sprhodes
Robert: I appreciate your enthusiasm to get this enhancement fixed.

However, I do hope you realize that this is not a priority for 1.0, probably
will not be fully worked on until after 1.0, and even if someone handed us a
bunch of code that we could use right now at the moment, I don't think it would
be turned on by default.  It might go into the source tree IF it got fully
reviewed reviewed right away (that might be difficult since non-essential bugs
like this are likely to get less focus), but expect it to sit alongside the
Calendar until after 1.0 is out the door.

Robert, also please realize that just because there are not many comments in
this bug at the current time does not mean this will never get done.  It just so
happens that right now, there are more important bugs to fix, like the crashers,
and performance bugs, etc.  Please don't push this too hard just yet.  I realize
you want this which is why you filed it, and don't get me wrong, I would love to
see this implemented too.  But do realize that this is not high on the priority
list, nor should it be.  This bug is not the only bug that needs to be fixed
right now (especially with a 1.0 release on the horizon).

Patience is a virtue :)

Also, I would ask restraint in blindly re-assigning bugs to others who have only
expressed 'interest' in something.  Especially if the bug is assigned to nobody
because then it prevents others who are looking at bugs assigned to nobody from
finding this bug. Also, perhaps sprhodes@lycos.com does not want the bug
assigned to him.  Perhaps he is on vacation and will not see this bug for
another few weeks, a few weeks that someone else could have worked on this. 
(Perhaps he welcomes the assignment as well, but you do not know one way or
another).  For that reason, I am re-assigning to nobody and if sprhodes does
want this bug, he is more than welcome to take it back at any time.
Assignee: sprhodes → nobody
> Also, perhaps sprhodes@lycos.com does not want the bug
> assigned to him.  Perhaps he is on vacation and will not see this bug for
> another few weeks, a few weeks that someone else could have worked on this. 
> (Perhaps he welcomes the assignment as well, but you do not know one way or
> another).  For that reason, I am re-assigning to nobody and if sprhodes does
> want this bug, he is more than welcome to take it back at any time.


Christopher,

It's Ok, I asked Robert to assign this one to me. I do intend to work on this. 
Please re-assign back to me, unless there is some outstanding reason not too.


:) Sorry for any confusion then.  From an outsider's standpoint without knowing
any arragements, it does appear that there is some anxiety hovering over this bug.
Assignee: nobody → sprhodes
I assigned it to him since he is willing to work on it.  Even if he doesn't 
finish, it will give someone else a basis to work off of. I know it won't be done 
before 1.0, but why waste time?  If he is willing to work on this, why not?  
Others obviously could join at will.
Status: NEW → ASSIGNED
Way back at the very beginning, the very day after the initial release (April 1,
1998), I offerred to work on this:

http://groups.google.com/groups?selm=Pine.LNX.3.96.980401040150.13172A-100000%40escher.ties.org

Nobody paid any attention to me.  (No, it wasn't an April Fool's joke.)  I've
been interested in doing this since the beginning.  I've implemented the TELNET
protocol from the RFC's before.  I don't know how to connect it into Mozilla,
and it's a huge moving target.  Nobody seemed inclined to help me with some
pointers on how to get started, so I gave up.  Three and a half years after I
offer, it showed up as this RFE.  It figures.  *sigh*

Well, I'm still willing to consider working on this, if I can find a mentor to
help me navigate through the Mozilla jungle.  As it stands, I wouldn't have a
clue where to begin.  Or is it actually being worked on now?  I just don't know
what I should be doing, or if I should even try anymore...
Phillip: -> Deven?

Deven: Phillip (the current assignee) may be able to help introduce you to the
codebase. Of course, #mozillazine and #mozilla on irc.mozilla.org are also good
resources for Mozilla info.

irc://irc.mozilla.org/mozillazine
irc://irc.mozilla.org/mozilla
Phillip, are you actively working on this and making progress with it, or are
you mostly trying to keep it from being orphaned?  I'm willing to have it
assigned to me *if* someone can help me get oriented enough that I'll be able to
make some progress on it.  However, my free time is always limited, so I don't
know how long it might take me -- if you're making rapid progress, I'd hate to
interfere.

What should I do?  (Perhaps I need to take a closer look at chatZilla and see
how that's implemented?)
Phillip started a project called termzilla at mozdev.org
<http://termzilla.mozdev.org/> specifically to fix this.
<i>Phillip, are you actively working on this and making progress with it, or are
you mostly trying to keep it from being orphaned? 
</i>

It's more like "I want to be actively working on this, but haven't had time to 
do much."

<i>I'm willing to have it assigned to me *if* someone can help me get oriented 
enough that I'll be able to make some progress on it.  
</i>

Sounds like you're in pretty much the same boat as me, then. I'm a programmer, 
but I'm not that familiar (yet) with Mozilla internals.  Learning the Moz 
basics, which is pretty much required to implement something like this, is what 
I haven't really had time to sit down and do... <sigh>

If you would like to take this bug, and you have more free time than me, I'll 
happily hand it over to you.  Or, if you want to try to collaborate on this, we 
can leave it assigned to me.  I'm interested in working on it, either way.


<i>However, my free time is always limited, so I don't
know how long it might take me -- if you're making rapid progress, I'd hate to
interfere.
</i>

See above.  Lack of time has been the biggest impediment to me really getting 
rolling with this.  School + work != free time for working on OSS stuff.

<i>
What should I do?  (Perhaps I need to take a closer look at chatZilla and see
how that's implemented?)
</i>

As somebody pointed out, I set up a mozdev project for this RFE.  It's at 
termzilla.mozdev.org.  We can still use that as a "staging ground" for work on 
this. If you're interested, I'll set you up with cvs access and all the other 
stuff.  We can also use their mailing lists facility to communicate.  People 
seem to not like it when the bugzilla bugs get too "chatty."

I would recommend looking at Chatzilla, as a starting point.  In fact, that's 
exactly where I plan to start. I got as far as downloading the source, unzipping 
it, and getting distracted by goings-on at work.

Having somebody else to work with could help spark my motivation to get rolling 
on this, though.  Drop me a private e-mail and we can talk some more, if you're 
interested.
Hmmm. That didn't come out quite right. I could have sworn that you could embed 
HTML in these comments.. guess not... my bad. :-(
Phillip,
If you aren't getting anywhere, I think it is best to open the bug for someone 
who can handle it, and you can involve yourself and learn on this one, maybe take 
on another project later.  Right now, time is just being wasted.  Granted it's 
not going to be in 1.0, there is still reason to get moving.  This isn't an 
overnight project.  This has been around for months, and has gone nowhere 
productive other than ideas.  It will take quite some time to get a working 
client for even beta use.

Just for quick reference, here are basically what it should include:

A few things that anyone who wishes to take on the project should note for what 
should be in this:
 - terminal emulation (vt100/vt102/etc.,arrows keys,ANSI color)
- SSH support
- configurable backscroll buffer
- ssh support
- client scripting
Some Stuff I liked in MacTelnet that I think it should include (in no order):
- support for FTP on the client and/or server sides, with either an anonymous or 
authenticated server 
-  support for PC ANSI colors and graphics, and styles such as blinking, bold, 
and underlined text 
- automatic terminal cursor positioning using the mouse, by command-option-
clicking in a terminal screen 
- an incredibly powerful text editing interface: drag and drop support, double-
click to select words, triple-click to select an entire line of text, shift-click 
to extend selections, command-click to open selected URLs, and option-drag to 
create purely rectangular text selections 


Lastly:
Check out:
http://macssh.com/

It contains lots of links to open source projects relating to SSH and telnet.  I 
think it could be a real benefit to someone with programming experience who needs 
a little help getting started.
*** Bug 139644 has been marked as a duplicate of this bug. ***
It's time to open up this bug.  It's almost a year, and no sign of any progress.  
I think it would be best if someone with the time takes a stab at this.  No 
offense to Phillip Rhodes, but this isn't very productive.  
Assignee: Phil_Mozilla → blaker
Status: ASSIGNED → NEW
QA Contact: sairuh → paw
Robert, not to bust your bubble, but this isn't exactly the top priority.  I
think that the previous assignee is still more likely to fix this bug than
anyone at Netscape is.  And then, even if someone does implement it, they would
have an uphill battle convincing everyone that it should be a part of Mozilla,
and not an add-on at mozdev.org for example.  However, maybe someone else will
come along and do this.  So I'm assigning it to nobody for the time being (where
all lonely bugs end up).

If someone actually has the time to fix this, and wants to fix this, then assign
it to yourself.  Otherwise, please leave it in the feature bin.
Assignee: blaker → nobody
Keywords: helpwanted
Too bad, this is something I was really looking forward to.
Christopher, Philip doesn't have experience with Mozilla yet, nor does he seem to 
have the time.  It shouldn't be assigned just to keep it from being orphaned.  I 
don't think it would ever get a second thought.  
Guys, you all have my sincerest apologies for not making some progress on this.
 This is something that I very much *want* to work on, but unfortunately the day
to day demands of work, school, etc. just keep getting in the way.

Robert, no offense taken from your earlier comment. I've been meaning to make a
post here for a while, saying that if somebody else wanted to take over this, to
please do so...  It's still my intention to try to get something going at some
point in the future, but the bug remaining un-owned for now is fine by me... and
if somebody else with more time comes along and starts on this, I'll just try to
help that person (or persons) with their efforts...

I'm still interested in working on this, but lack of free time remains a
problem.  I've asked before, and I'll ask again -- is there anyone willing to
play Mozilla mentor for me and give me a hand getting oriented and started?  Now
that 1.0 is out, I'm assuming that Mozilla is somewhat less of a moving target
if APIs have been frozen, but it's still an enormous project and I don't know
where to start.

Is chatzilla the best place to look at as an example?  XMLterm?  Something else?
Yes, Chatzilla is a good place to look at for a general idea.  If you need
specific help, Chatzilla is good anyway since you can hop on Moznet and ask
questions there.
Summary: [RFE] XP Telnet client → XP Telnet client
I'd love to see this feature. Idea: if it fits the Mozilla crypto framework,
perhaps we can add support for (START)TLS. Together with client certificates,
that  would give roughly the same functionality as the SSH protocol.
If somebody's looking for a codebase to adapt, MOOzilla
http://www.moo.ca/moozilla might be a worthwhile starting place.
I dunno if that'd be kosher...MOOzilla is GPLed only, and I don't think you can
legally use GPLed code in an MPLed codebase.
As the maintainer of MUDzilla (http://mudzilla.mozdev.org/) and the secondary
author of MOOzilla (http://www.moo.ca/moozilla), I'd be delighted to see either
piece of code used as the basis of a Telnet application.

Note that both MUDzilla and MOOzilla are based around the concept of
line-by-line telnet mode, not character-by-character.  In the end, I doubt
there'd be much to salvage.  However it might serve as a valuable framework to
get started with.  We couldn't have programmed our two aps without using
Chatzilla as a starting point, even though there's virtually no Chatzilla code left.
I'd say clarification were needed on GPL code in Mozilla before going any further.

I would think the perfered client would be MPL, like Mozilla, and Chatzilla.

Can anyone clarify on using GPL?
I just heard from the other author of (MOO|MUD)zilla.  He states:
> We would be happy to offer you a relicensed
> version of MUDzilla or MOOzilla if necessary.
So licensing issues aren't a problem.

Your real problem is going to be speed.  How do you intend to display the text?
 We used an HTML page and simply added a new TR/TD at the bottom for each line
of new text.  Worked great for line-by-line text.  But it is close to the limits
of usability due to slow update speed (chatting is fine, but listing code is slow).

A Telnet client with ANSI support needs to be able to randomly address each
character on the screen.  The only Mozilla-based mechanism I can think of is a
big grid of characters in a PRE tag (or CSS equivalent), each with an individual
colour/style tag.  I do not believe that JavaScript can be made to run fast
enough to update the contents of this grid in a character by character mode.

The only option I can think of is to create a new widgit in C for your display.
 Please think outside the box and prove me wrong.
I believe the best way is to start with a telnet app and adapt it to have a XUL 
interface. If there are any open-source telnet apps available, perhaps they can 
be used as a codebase.
I've got too many bug on existing features to track this...

Once you build a working prototype that is checked into the trunk, please create
a bug that is "add telenet: protocol hanlder to use XP client".

When you do, please put that in Networking, and I can work on testing the hookup.
In response to comment #3, #4, and #6, there is an alternative to this which can
be done by using the HTML's Iframe tag.   :-)
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
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
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
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
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.