User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 my daily routine is to copy a couple of lines from a HTML table (in phpmyadmin) into an excel sheet to do some data manipulation. i created the excel just as needed. started this routine in FF3. now when copy / pasting my HTMl lines into the excel it does no longer fill the cells of the excel but everything goes into the first cell of my sheet. Reproducible: Always Steps to Reproduce: 1. mark HTML table in browser (e.g. phpmyadmin) 2. copy selected cells (cmd+c) 3. paste into excel sheet (cmd+v) Actual Results: result is no longer added into single cells in my spreadsheet but into one cell which now contains all the data. Expected Results: instead of pasting all data into one single cell the actual table data should be spread into the appropriate number of cells like it was in FF3.
looks like a dupe of bug 137450 but that's not possible if it's a regression between FF3 and FF3.1
sounds pretty similar but i do not have the problem in ff3 - it just appeared in ff3.1 beta 2 for me.
That is almost certainly a regression from bug 428096. I noticed recently that copy/pasting tabular data in a TextEdit .rtf document, all tabs are lost. (I don't have Excell to test this issue) bug 466599 comment 16 has a testbuild linked that improve some things with copy pasting for that bug, I don't think it would fix this particular issue, though.
Assignee: nobody → joshmoz
Component: General → Widget: Cocoa
Product: Firefox → Core
QA Contact: general → cocoa
Version: 3.1 Branch → Trunk
I confirm the regression between Firefox 3.0.x and 3.1. I don't have a regression range though, but bug 428096 is definitely likely.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The test build mentioned in comment 3 does not solve the problem.
This broke between 2008-11-06-02 and 2008-11-07-02, which is when bug 428096 landed. I'm using http://www.w3schools.com/html/html_tables.asp to test. More and more I think bug 428096 didn't get adequate testing before landing and with no automated tests for it, it's scary having it in 1.9.1, in my opinion.
= See also = bug 470642 ---------------------------------------------------------------------------- Summary|System Services |Send rich text to Mac OS X |(interapplication |Services |communication on Mac OS X): | |provider services to | |support richer text in | |Mozilla applications |
I don't have Excel to test this - can I get clear repro steps that don't involve Excel?
(In reply to comment #8) 1. Copy some tabular data (multiple cells) (e.g the result of a search query on Bugzilla) 2. open a .rtf document in TextEdit.app 3. Paste You'll notice that everything is pasted on one line, each cell content separated by one space character. If you paste the same selection in plain text document, each cell is separated by a 'tab' character. I don't have Excel either, but I strongly suspect that this is the reason why everything ends up in one cell in that app.
Created attachment 360126 [details] [diff] [review] rtf approach v0.5 This doesn't work, just storing the code here. This is an attempt at basic declaration sorting and RTF export when we have HTML to export.
Turns out this bug has nothing to do with what formats we export or in what order. The problem is that when you copy table rows, Gecko sends HTML starting with <tr> and ending with </tr>. It does not include an actual <table> tag so receivers (Excel, TextEdit) don't interpret the HTML as tabled and break the paste into rows. If I wrap the copied row HTML in <table></table> everything works just fine.
See also bug 137450, which is basically the same bug for Windows.
The necessary fix for this is pretty clearly the same as the necessary fix for bug 137450. I'm going to clear blocking here, dupe this against bug 137450, and request blocking on bug 137450.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 137450
You need to log in before you can comment on or make changes to this bug.