Open Bug 242580 Opened 20 years ago Updated 3 years ago

If you select a table w/o starting inside it, Copy/Paste in Composer does nothing

Categories

(Core :: DOM: Editor, defect, P5)

defect

Tracking

()

People

(Reporter: steve.swanson, Unassigned)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040504

If you start inside the table, you get different behavior.  (The Paste works 
but changes the shape of the table.)

Reproducible: Always
Steps to Reproduce:
1. Start up Composer
2. Type "Start"
3. Insert a 2x2 table
4. Enter "x", "y", "z", "w" into the cells
5. Caret right once to get out of the table
6. Type "end"
7. Use the mouse to select from the end of the first line to the right of w
8. Edit Copy
9. Move the insertion point
10. Paste

Actual Results:  
Nothing happens

Expected Results:  
Insert the table.

Copy/Paste without Formatting does work, proving there is data on the 
clipboard.

If you select from the t to the e, the paste works as expected.
I discovered this bug while searching for an earlier report of the problem in 
bug 275555.  I suspect that *is* a dupe of this -- the behavior is identical, 
but the contents of the clipboard, which I believe are the crux of this bug, are 
somewhat different.

I'm curious whether this bug manifests on non-Windows platforms, since I have no 
idea how the clipboard is structured on those systems.


(In reply to comment #0)
> 7. Use the mouse to select from the end of the first line to the right of w

Note that "first line" in this context means the line (or some portion) that 
reads "start".  If you select from the first cell to the last cell, you get 
different results: the table pastes, but as a 1x4.  This is a separate bug.


The following is about how this bug appears in Windows 2000 (and presumably XP):

When the data is copied to the clipboard, it is stored in a number of different 
formats.  There are two plain-text representations ("Text" and "OEM Text") and a 
MS-defined "HTML Format" which stores the HTML data within a context, with 
pointers to the beginning and end of the portion that was actually being copied, 
such as (from the working variation of the example data in comment 0):
  <html><body>
   <!-- fragment begins -->
   start<br>
   <table>
    <tr><td>x</td><td>y</td></tr>
    <tr><td>z</td><td>w</td></tr>
   </table><br>
   end
   <!-- fragment ends  -->
  </body></html>

The clipboard also contains three sections presumably designed by Mozilla; these 
parts are labelled:    text/html   text/_moz_htmlcontext   text/_moz_htmlinfo
They are encoded in 16-bit Unicode.  Using the same example, which WORKS, these 
parts are (essentially):
  text/html
  ---------
   start<br>
   <table>
    <tr><td>x</td><td>y</td></tr>
    <tr><td>z</td><td>w</td></tr>
   </table>
   end

  text/_moz_htmlcontext
  ---------------------
   <html><body></body></html>

  text/_moz_htmlinfo
  ------------------
   0,0


Now, the variation that does *not* work has the same 'htmlcontext' and almost 
the same text/html part, less the text "end" that follows the end of the table.
What appears to be the main difference is the 'htmlinfo' section, which is
"0,4" instead of "0,0".

The variation where only the table is selected, without including any of the 
surrounding text, has a different 'htmlcontext' which goes as deep as the <tr> 
tag, where as the text/html only includes the <td> information.
That variaton's 'htmlinfo' is *also* "0,0" and the paste works (with the caveat 
the <tr> data is bogus, resulting in the 1x4 paste).

The data from bug 275555, in which copied from the browser does not paste into 
the mail composer, has an 'htmlinfo' section of "2,2".

It appears that either the editor is misinterpreting the htmlinfo from the 
buffer, or the copy mechanism (from both the editor and the browser) is not 
storing that information correctly.
OS: Windows XP → Windows 2000
QA Contact: bugzilla → editor
Assignee: mozeditor → nobody
Confirmed. Affects all instances of the editor, probably since 2003.
Thunderbird, Nvu, BlueGriffon, Postbox, all affected.
Amazing this remained so long under the radar...
Severity: normal → major
OS: Windows 2000 → All
Hardware: x86 → All

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: major → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.