46459 - Paste Special (dialog with options for pasting)

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, enhancement)

Description

[Akkana Peck]

Periodically we've talked about having several different copy/paste menus that
let you choose the level of formatting, the mime type, etc.  This is a
placeholder for developing ideas for exactly what these menus should look like
and should do, and then, eventually, for doing them.

Comment 1

[Akkana Peck]

Future.

Comment 2

[Akkana Peck]

A message describing this in more detail:
--------
Beth Epperson <[e-mail]>        12/03/99 11:35
Subject: Copy/Paste issue

Hi guys, 

I wanted to finalize a discussion we had on Wednesday. It was a short discussion
in
Charley's cube, but it was a very important one. You were talking about a
copy/paste issue,
and whether we should bring the format of the object. I mentioned adding an
additional paste
option -- specifically, I think it should be  "Paste with format" 

This is what I would like to see implemented: 
1. If the user selects the default paste, then just the character(s) gets copied
to the clipboard
and when pasted, it adopts the parent format. This is how 4.x handles this
today. 
2. If the user selects to paste with format, then the format elements should go
with it. The
selection should move outward until a block/select element is reached. For
example: 

          <P>blah blah <I><B>abc</B></I> blah blah </P> 

if the user selects the "b" in abc, what gets placed in the clipboard should be: 
         <I><B>b</B></I> 

when it gets pasted, it would then also adopt the parents format -- so if this
was pasted into
another para, the user would get this: 

           <P>foo foo <I><B>b</B></I> foo foo</P> 

So, if the user were to select "level 1" from this: 
          <H1>This is a level 1 heading</H1> 

then they would get this in the clipboard: 
        level 1 

and when it gets pasted, this is what they would get: 

         <P>foo foo level 1 foo foo</P> 

Granted, there will be instances where we will not do the right thing for the
user, but I think
those will be the exception and not the rule. 

Any comments? 

Comment 3

[Akkana Peck]

And some responses:
----------

Beth Epperson <[e-mail]> 12/03/99 13:50
Subject: Re: Copy/Paste issue

Charles Manske wrote: 

  Beth Epperson wrote: 

    Hi guys, 

    I wanted to finalize a discussion we had on Wednesday. It was a short
discussion in
    Charley's cube, but it was a very important one. You were talking about a
copy/paste
    issue, and whether we should bring the format of the object. I mentioned
adding an
    additional paste option -- specifically, I think it should be  "Paste with
format" 

    This is what I would like to see implemented: 
    1. If the user selects the default paste, then just the character(s) gets
copied to the
    clipboard and when pasted, it adopts the parent format. This is how 4.x
handles this
    today.

  I agree with Joe's comment: What 4.x (and Word) does is always copy the text
attributes
  with the text. When pasted, these attributes are pasted. And it's important to
note that the
  insertion does not inherit the attributes at the insert. Thus if you past
non-bold text into
  existing bold text, the pasted text is not bolded.

you're right, 4.x does in some cases copy the surrounding element as in bold or
italic, but
those are not the only elements that provide visual formatting to the user -- in
other cases
4.x does not carry over the format, case in point: 
1. select text from a heading 
2. paste into a para 
-- you clearly do not bring over the format - which, if it's an H1 would be bold
and 22 point
font. In this case, 4.x is not consistent to the user 

just to drive this home, place an address element around some text, it looks
italic doesn't it?
Now, paste that into a para -- what do you get? In 4.x, the copy/paste is not
bringing over
the format 

In Word, if I highlight and copy a portion of the heading, the format of the
heading is brought
over with the copy. If I paste italic text within a bold, the bold is ended, the
italic text is
inserted and then the bold resumes. But I don't think that is the right thing to
do -- I think the
paste should inherit the destination format and if I say -- hey I want the
current format to go
with it, then I would expect to have the italic or underline or bold to be their
on the paste as
well as whatever format there is at the destination point. 

Our problem is with block/select elements such as headings, span and address.
How do we
grab the associated format from those elements? That is where I see the problem. 

  Thus the default case (for 4.x) is already "Paste with format". This is how I
would like 5.0 to
  behave, but it is not trivial to do from the copy perspective: Because the
text attributes are
  parents of the text nodes being copied,  we would have to search up the parent
chain and
  clone attribute nodes and add them to the copy fragment.

but that is what we should allow to happen. Shouldn't we be picking up the
surrounding
element start and end tag? Don't we already know that from the DOM? 

  There are really 3 issues: 
  1. Do you include attributes whose nodes are not included within the
selection, but are
  parents of the selection, with the copy (currently no).

do you mean the parent element? or do you mean all surrounding inline elements?
It would
depend on how far you move out, for example, if the selection was this: 
    <u><b><i>foobar</i></b></u> 
wouldn't you want all three elements? what if this was all within a blockquote
-- would you
expect to also copy the indentation? I certainly wouldn't 

  2. Do we include attributes when pasting (currently yes)

what attributes? No we don't -- look at the heading and address example above 

  3. Do we split the DOM tree when pasting so the paste does not inherit the
attributes.

you mean from the old parent or the new parent? if you are referring to the new
parent, we do
inherit, if I copy bolded text into an <I></I> -- the pasted text is bold and
italic -- that is what
I would expect 

    
  The answer to all 3 questions is "yes" for Word and Composer 4.x. 

  I think the issue we were discussing is to add a "paste and inherit
attributes" to get the
  behavior that is currently exhibited by the editor, which is to insert the
text and inherit the
  existing attributes. This seems useful to expose in the UI, but probably
shouldn't be the
  default behavior. 

      
    2. If the user selects to paste with format, then the format elements should
go with it. The
    selection should move outward until a block/select element is reached. For
example: 

              <P>blah blah <I><B>abc</B></I> blah blah </P> 

    if the user selects the "b" in abc, what gets placed in the clipboard should
be: 
             <I><B>b</B></I> 

    when it gets pasted, it would then also adopt the parents format -- so if
this was pasted
    into another para, the user would get this: 

               <P>foo foo <I><B>b</B></I> foo foo</P>

  What is the "parents format" that is being adopted? The paragraph? A better
example is if
  you are pasting into: 
  <P><U>foo foo foo foo</U></P> 
  The way we do it now (inherit the "parent's format") is: 
  <P><U>foo foo <I><B>b</B></I>foo foo</U></P> 

  The way Word and 4.x Composer do it is to NOT inherit the underline: 
  <P><U>foo foo</U> <I><B>b</B></I><U>foo foo</U></P> 
    

      
    So, if the user were to select "level 1" from this: 
              <H1>This is a level 1 heading</H1> 

    then they would get this in the clipboard: 
            level 1 

    and when it gets pasted, this is what they would get: 

             <P>foo foo level 1 foo foo</P>

  Be careful about block level attributes, such as <H1>, an text attributes,
such as <B> and
  <I>. Here's where the problem gets messy. I think we should search up the
parent chain to
  get text attributes only. And we always inherit the block attributes of the
destination, as your
  example demonstrates.

that is what I was saying -- inherit the destination 

Let me try this again -- there are two states that we should allow on paste: 
1. as if the selected text was void of any elemental structure or format and
when pasted it
inherits the element structure of the destination 
2. carry the existing inline element (b, i, u, etc.) to the destination, and
also inherit the
destination format, but do not carry over block/select element attribute values
-- that would
be the 3rd state 

I don't think these next 2 states are worth our effort -- 

the 3rdstate would be: 
carry the existing element structure format and override the destination format 

a 4th state would be: 
carry the existing element structure to the destination (whether it be an inline
or block level
element), and override the destination structure to the appropriate constructs
if the paste
operation rendered invalid HTML. So if I copy contents of a heading and paste it
into a para,
the para would break, a new heading would be inserted and then the remainder of
the para
would be prefaced with a new para element start tag 

      
    Granted, there will be instances where we will not do the right thing for
the user, but I
    think those will be the exception and not the rule. 

    Any comments? 

    -- 
    Netscape Editor development 
    Pager: 888.319.2088 
    Email pager: [e-mail] 
    Quick email: [e-mail] 
     

-- 
Netscape Editor development 
Pager: 888.319.2088 
Email pager: [e-mail] 
Quick email: [e-mail] 
  



   From: 
          Beth Epperson <[e-mail]>
                                                                       12/03/99
14:55

  Subject:
          Re: Copy/Paste issue
      To: 
          [e-mail]



  

Joe Francis wrote: 

    

  Beth Epperson wrote: 

      
    you're right, 4.x does in some cases copy the surrounding element as in bold
or italic, but
    those are not the only elements that provide visual formatting to the user
-- in other
    cases 4.x does not carry over the format, case in point: 
    1. select text from a heading 
    2. paste into a para 
    -- you clearly do not bring over the format - which, if it's an H1 would be
bold and 22
    point font. In this case, 4.x is not consistent to the user 

    just to drive this home, place an address element around some text, it looks
italic doesn't
    it? Now, paste that into a para -- what do you get? In 4.x, the copy/paste
is not bringing
    over the format 
     

  I don't think we should go down the path of trying to grab the "paragraph
format" of the
  selection unless that container node is entirely in the selection.

I agree with you 100% 

    
  It may seem natural to say "it looks italic so we should make it paste italic"
but leads to all
  kind of problems with style sheets.  We shouldn't do this kind of thing half
way: if you are
  going to preserve an italic look because of an address, you should preserve it
because of
  a style sheet.  But the target of the paste may not have the same styles. 
Worse yet, the
  target of the paste may have a stlye for address tags that makes them bold. 
Now you copy
  the address tag to try and get the same look, and all you've done is give the
user a different
  (and wrong) look.

I agree, that's why I would like to see grabbing of format elements and not
block elements or
block element format 

    
  We already do things differently for block nodes vs inline nodes: if you
select a word in a
  paragrah and say "bold" you get a bold word, not a bold paragraph.  But if you
say "heading
  1", the whole paragraph becomes a heading.  So having a block/inline
distinction for
  copy/paste is not necessarily a bad thing.

I agree 

      
    In Word, if I highlight and copy a portion of the heading, the format of the
heading is
    brought over with the copy.

  I think Word is really weird there.

no kidding -- I get so bloody aggravated at Word 

    If I paste italic text within a bold, the bold is ended, the italic text is
inserted and then the
    bold resumes. But I don't think that is the right thing to do -- I think the
paste should
    inherit the destination format and if I say -- hey I want the current format
to go with it,
    then I would expect to have the italic or underline or bold to be their on
the paste as well
    as whatever format there is at the destination point. 

    Our problem is with block/select elements such as headings, span and
address. How do
    we grab the associated format from those elements? That is where I see the
problem.

  Span is different from heading and address.  Span is inline.  Also, span does
not imply any
  particular stlye.  Only if a style is specifically applied to the span will it
change the
  appearance of anything.

it is also a select element -- no? Span has its own issues, for example: 
span.foo {some such format} 
span.foo P {some other format} 

if you copy something inside the para and paste it outside the para -- the
format will be
totally different 

  My solution: do not attempt to grab style info from block elements.  It
doens't make any
  sense to do this unless you go all the way andask the stlye system to resolve
the style of
  everthing that is selected.  Only then will have all the info to do the job
rght at paste time,
  and then only if you are willing to potentially muck with a stlye sheet in the
target
  docuement.

I'm with you on that this 100% 

      Thus the default case (for 4.x) is already "Paste with format". This is
how I would like
      5.0 to behave, but it is not trivial to do from the copy perspective:
Because the text
      attributes are parents of the text nodes being copied,  we would have to
search up the
      parent chain and clone attribute nodes and add them to the copy fragment.

    but that is what we should allow to happen. Shouldn't we be picking up the
surrounding
    element start and end tag? Don't we already know that from the DOM? 

      There are really 3 issues: 
      1. Do you include attributes whose nodes are not included within the
selection, but are
      parents of the selection, with the copy (currently no).

    do you mean the parent element? or do you mean all surrounding inline
elements? It
    would depend on how far you move out, for example, if the selection was
this: 
        <u><b><i>foobar</i></b></u> 
    wouldn't you want all three elements? what if this was all within a
blockquote -- would
    you expect to also copy the indentation? I certainly wouldn't

  Exactly.  Let's either copy the stlye up to (but not including) the first
"block" ancestor, or not
  copy stlye at all. 

      

      2. Do we include attributes when pasting (currently yes)

    what attributes? No we don't -- look at the heading and address example
above

  We have to agree on our terms first.  I don't Charlie is including the block
elements in his
  definition of "attributes". 

      

      3. Do we split the DOM tree when pasting so the paste does not inherit the
attributes.

    you mean from the old parent or the new parent? if you are referring to the
new parent, we
    do inherit, if I copy bolded text into an <I></I> -- the pasted text is bold
and italic -- that
    is what I would expect

  What if you copy plain text and paste it into italic?  Is "plain" special?

this was the one scenario where I had trouble -- we do know that it is plaintext
right? Could
we gray out the Paste with format? 
  

-- 
Netscape Editor development 
Pager: 888.319.2088 
Email pager: [e-mail] 
Quick email: [e-mail] 
  



   From: 
          Beth Epperson <[e-mail]>
                                                                       12/03/99
15:02

  Subject:
          Re: Copy/Paste issue
      To: 
          Charles Manske <[e-mail]>
     CC: 
          [e-mail]



  

Charles Manske wrote: 

  I think MS changed this behavior in different version. In Word97 for Windows,
I just made a
  line with "H1" and a line with "normal". I copied some text from the middle of
the H1 line,
  pasted it into the middle of "normal" and it did NOT carry the H1 style. But I
think I've seen it
  do so in another version, which shows they are as confused as us!

that's weird -- I'm using word97 and it DOES bring it over -- now that is weird 
  



   From: 
          Beth Epperson <[e-mail]>
                                                                       12/03/99
15:07

  Subject:
          Re: Copy/Paste issue
      To: 
          [e-mail]
     CC: 
          Charles Manske <[e-mail]>, [e-mail]



  

Joe Francis wrote: 

    

  Charles Manske wrote: 

      
    So I would support having 3 paste modes, the first 2 being the ones you
suggest: 
    1. Paste without source style 
    2. Paste with source style 
    3. Paste only the style (This an added feature we played around with in
Gromit. It's similar
    to Word's "Format Painter"). The style from the source is applied to a new
selection.

  I think we are at least all in agreement on what we should do.  (Quick, lets
declare a
  consensus!)

I second that 

    

      
    One subtle, but important point is how you select. If you select the entire
line of an H1,
    then you will get all of it  (<h1>blah</h1>) to the clipboard. But if you
clicked and dragged
    carefully, you can select all of the text on an H1 line, but the <h1>
wouldn't be included in
    the selection. That problem always confuses users as the selection looks the
same to
    them!

  I can make it so that we always get the H1, or never do.  Let me know if
that's something we
  want to pursue.  Note that this potentially applies to things even higher up
than your
  immediate block parent.  For instance, if you ahve a list with only one list
item, and you
  select all of the list item text, I could cause the whole list to get copied.

I would think we would only want to bring the <LI> over - that is if they
selected the entire
line. I would suspect that the user would be more apt to want to paste the <LI>
within the
existing list. If the user highlights and copies just a portion of the list
item, I would suspect
they just want the text and not the <LI>. In this case the <LI> would be treated
as a block
element -- right? 

    

  -joe

-- 
Netscape Editor development 
Pager: 888.319.2088 
Email pager: [e-mail] 
Quick email: [e-mail] 
  



   From: 
          Beth Epperson <[e-mail]>
                                                                       12/03/99
17:13

  Subject:
          Re: Copy/Paste issue
      To: 
          Akkana Peck <[e-mail]>
     CC: 
          [e-mail]



Akkana Peck wrote: 

  Charles Manske wrote: 

    So I would support having 3 paste modes, the first 2 being the ones you
suggest: 
    1. Paste without source style 
    2. Paste with source style 
    3. Paste only the style (This an added feature we played around with in
Gromit. It's similar
    to Word's "Format Painter"). The style from the source is applied to a new
selection.

  Where are all these styles going to be visible, and are users really going to
discover and
  use them?  Well, maybe -- I use PasteAsQuotation in mail, so maybe people
would use
  these other paste modes. 

  As far as I'm concerned, the only one that really matters is the one that gets
called when I
  middle-mouse or [xulkey]-V.  That's the Paste that Imost people are going to
use 80% of
  the time. 

  By the way, why is this discussion on an internal list?  Don't we care about
what users
  might think about different selection modes? 

  Incidentally, all this "climb up and look at the parent" stuff is nontrivial
for copy, which is
  currently implemented via methods in nsDocument which loop over the whole
document
  and do IsInSelection() and then ToXIF on each node that appears to be in the
selection. 
  In order to do anything fancy like climbing up to the highest non-block node
we'd probably
  want to rewrite all of that stuff to use selection iterators.  Certainly
do-able, but not trivial. 

      ...Akkana 

Comment 4

[rubydoo123]

*** Bug 58807 has been marked as a duplicate of this bug. ***

Comment 5

[rubydoo123]

*** Bug 58807 has been marked as a duplicate of this bug. ***

Comment 6

[Jacek Piskozub]

*** Bug 88638 has been marked as a duplicate of this bug. ***

Comment 7

[rubydoo123]

wanted to capture what was last discussed with this issue:

Menu that contains something like this:

Paste Special
     Tables
          content and structure
          text only
          rows
          columns
          table
     Text
          text only
          text and format
          text and structure
     Links
          absolute
          relative

also, see bug 73286 and bug 41547

marking bug 88638 as a dup

Comment 8

[Syd Logan]

spam composer change

Comment 9

[Charles Manske]

Kathy and Akkana: There seems to be a lot to do here. The UI is easy, but the
core work looks involved. Given new priorities, what do you think we should do
now?

Comment 10

[Kathleen :Brade]

I think we should move this to Future for now.
We have a lot on our plates right now and this is a new feature.  We need to get 
what we have working correctly before we introduce new complex functionality.

Comment 11

[Kathleen :Brade]

*** Bug 103809 has been marked as a duplicate of this bug. ***

Comment 12

[Akkana Peck]

Agree with Kathy.  This would require some rules work from Joe, and I very much
doubt he'd have time for it, and he has more important things to work on which
would help composer a lot more.

Comment 13

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 14

[Mirek]

I would recommend the WordPerfect approach - the context menu
offers "paste"= paste with attributes of the text in the buffer
and "paste w/o font attributes"=the text is pasted w/o font formats.
I would also add "paste w/ no attributes", i.e.., just like typing the text
from the keyboard. See also bug 64647 (mail composition but idea is the same).

Comment 15

[Charles Manske]

*** Bug 64647 has been marked as a duplicate of this bug. ***

Comment 16

[Charles Manske]

Yes, pasting with control over formating is a very good idea!

Comment 17

[Jesse Ruderman]

The number one annoying bug for me in mozmail is that if I want to quote a web
page, I have to paste into notepad before pasting into message compose.  I don't
need the ten options from comment 7; I need Paste (Ctrl+V, keeps HTML structure)
and Paste Without Formatting (Ctrl+Shift+V, only keeps HTML block structure,
like pasting into notepad).  I could imagine occasionally wanting to "Paste with
plain-text mocking of inline styles" (similar to what "send html mail as plain
text" does), but I don't think adding that feature would be worth the confusion
to mail users trying to figure out which of the three paste options to use.

Brian and I wontfixed "copy without formatting" in bug 67142, and I think we
should do that here too by removing "copy" from the summary.  I also think we
should consider reopening bug 64647 for "paste without formatting", leaving this
bug open for a "Paste special..." dialog that has options involving relative
links, table cells, converting class styles to inline styles, etc.

Comment 18

[Peter Lairo]

Yes, "Paste without formatting" is simple to understand by most users. "Paste
Special" (and all its options) is probably more for people who know what they
are doing and want finer control. Therefore, it sounds like a good idea to
reopen bug 64647 and focus this bug on the "Paste Special" options.

Since "Paste without formatting" is a clearer approach, I suggest the it be
included in the context menus, and "Paste Special" be placed in the Edit menu.
Reason: MS Word has only "Paste" in its context menus and it is a pain to paste
unformatted text via the menu (4 clicks versus 2); plus in the menus it is
virtually undiscoverable by novices.

Comment 19

[Charles Manske]

Jesse and Peter: All are very good suggestions! We'll get to it next round.

Comment 20

[Jacob Eisinger]

*** Bug 133408 has been marked as a duplicate of this bug. ***

Comment 21

[Samir Gehani]

Composer triage team: nsbeta1-

Comment 22

[Robert Kaiser]

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

Comment 23

[Robert Kaiser]

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

Comment 24

[Robert Kaiser]

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

Comment 25

[Robert Kaiser]

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

Comment 26

[Robert Kaiser]

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

Comment 27

[Robert Kaiser]

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

Comment 28

[Robert Kaiser]

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

Comment 29

[Robert Kaiser]

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