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)
Core
DOM: Editor
Tracking
()
NEW
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.
Comment 1•19 years ago
|
||
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
Updated•17 years ago
|
QA Contact: bugzilla → editor
Updated•17 years ago
|
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
Comment 3•3 years ago
|
||
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.
Description
•