154401 - cannot paste HTML on clipboard into composition or editor windows

Status: RESOLVED FIXED

(SeaMonkey :: Composer, defect)

Description

[Judson Valeski]

copied text can not be pasted into composer or mail composition windows (does
work for text areas) using today's win2k trunk build.

steps to reproduce:
1. copy text from a browser window or a mail message.
2. try and paste that text into an editor document or a mail compose window.
3. notice you can't paste (keyboard or otherwise), even though the menu item
indicates you can paste.

expected results are that you can paste.

Comment 1

[John "AntiTuX" Dee]

WFM on today's trunk (2002-06-26-04) Windows NT 4.0

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I see this in a Windows debug build from last night.

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Looks like what's happening is that nsHTMLEditor::GetListAndTableParents is
returning NS_ERROR_FAILURE because listCount is 0.  This causes
nsHTMLEditor::InsertHTMLWithCharsetAndContext to fail.

Comment 4

[kinmoz]

Just another data point, I can't reproduce this problem in my 10am-ish Win2K
debug build.

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Based on Linux nightlies this broke between the 2002-06-25-08-trunk build and
the 2002-06-25-21-trunk build.

Comment 6

[Akkana Peck]

Add Joe, who's most familiar with the paste/edit rules code.

I do see this on my linux build updated this morning.  I can copy from html and
paste into a plaintext app, or copy from plaintext (either mozilla or other app)
and paste into composer; just can't copy html from mozilla and paste into composer.

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Since some people are having trouble reproducing, I'll give (in painfully
detailed form) the steps that I used to reproduce on Linux nightlies and on my
own Windows build:

 1. start mozilla
 2. go to http://www.mozilla.org/start/ if you're not there already
 3. Select, in the paragraph beginning with Congratulations, the text "eans that
you've volunteered to become part of the Mozilla testing community.  Great! 
Welcome aboard.  Helping out w"
 4. Edit | Copy
 5. Window | Composer
 6. Edit | Paste

Expected results:
 * text shows up

Actual results:
 * nothing happens (NS_ENSURE_TRUE debugging printf in debug builds)

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Backing out caillon's checkin from yesterday fixes this problem for me:

http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&branch=HEAD&cvsroot=/cvsroot&date=explicit&mindate=1025035020&maxdate=1025035620&who=caillon%25returnzero.com

Comment 9

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Perhaps this should have been a smoketest blocker today -- putting on list for
tomorrow at least.  It would be good to get a fix for this bug in sometime today.

Comment 10

[John "AntiTuX" Dee]

This bug is not a smoketest blocker, because it's not tested during smoketests.
This bug *IS* a blocker though, and the sheriff should attempt to get some
traction on this.
Only blockers that stop the smoketester from finishing his tests are smoketest
blockers, which this bug doesn't do, as cut&paste are not tested.
I'm removing the smoketest keyword.

Comment 11

[Asa Dotzler [:asa]]

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

Comment 12

[Asa Dotzler [:asa]]

Then I'm making an executive decision and saying that the tree will not open
tomorrow unless this is fixed, I'm half tempted to close it now. If there are
objections to using the normal keyword-severity combo to ensure that the tree
stays closed then I guess I'll police in the morning and make sure that the tree
doesn't get opened until this is fixed. 
We've used the keyword-severity combo of smoketest blocker to keep the tree
closed in the past even if the bug wasn't specifically tested in the smoketests.
I think this is a reasonable action if the problem is sufficient to hold the
tree closed, regardless if it is on the list of smoketests.
 

Comment 13

[Akkana Peck]

Is there any chance of adding copy/paste to the smoketests?  It's quite
important to a lot of people.

But it's also true that we have not in the past required that something be in
the official smoketests in order to be a tree blocker.

Comment 14

[Christopher Aillon (sabbatical, not receiving bugmail)]

I have a fix for this which I will post shortly.

Comment 15

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Patch to fix v.1.0

Comment 16

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 89324 [details] [diff] [review]
Patch to fix v.1.0

>+   * Returns true if the nodes are both in the same document or
>+   * if neither are in a document.

"neither is"

Fix that, and r=bzbarsky (and yes, I've tested this too...)

Comment 17

[kinmoz]

Comment on attachment 89324 [details] [diff] [review]
Patch to fix v.1.0

sr=[e-mail]

Comment 18

[Christopher Aillon (sabbatical, not receiving bugmail)]

Checked in.

Comment 19

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

"neither are".  The rule I learned was that all words for zero take the plural,
except for "none", which is a contraction of "not one". :-P   I could be wrong,
though.

Comment 20

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

OK, never mind.  bz pointed out that either works just like none, since it's a
contraction of not either.  See also http://www.bartleby.com/116/202.html , rule 6.

Comment 21

[Alfonso Martinez]

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

Comment 22

[Rainer Bielefeld]

It seems that the problems reported with bug 154659 are no longer existant in
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1a+) Gecko/20020629

Comment 23

[David Oppenheimer]

where can I download a working binary which has Bug 154401 fixed?

Comment 24

[Boris Zbarsky [:bzbarsky]]

ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/