Last Comment Bug 137450 - Problem copying and pasting a table from a web page to excel
: Problem copying and pasting a table from a web page to excel
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal with 42 votes (vote)
: mozilla15
Assigned To: lwz
:
Mentors:
http://msdn.microsoft.com/workshop/ne...
: 154073 172424 183154 191782 220501 247678 264959 272159 272672 276688 276916 298739 303164 303736 331289 338270 397932 470384 504671 512068 569200 638439 673802 (view as bug list)
Depends on: 173388
Blocks: 470384
  Show dependency treegraph
 
Reported: 2002-04-14 17:53 PDT by Patrick Gade
Modified: 2012-05-16 19:55 PDT (History)
50 users (show)
ryanvm: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
example of pasting problem (13.00 KB, application/vnd.ms-excel)
2002-04-16 01:23 PDT, Patrick Gade
no flags Details
Possible fix - content changes (11.35 KB, patch)
2005-05-30 07:18 PDT, Ted Mielczarek [:ted.mielczarek]
no flags Details | Diff | Splinter Review
Possible fix - widget/win32 changes (10.24 KB, patch)
2005-05-30 07:22 PDT, Ted Mielczarek [:ted.mielczarek]
no flags Details | Diff | Splinter Review
Combined and updated to trunk (9.74 KB, patch)
2006-03-03 18:58 PST, Ted Mielczarek [:ted.mielczarek]
neil: review-
Details | Diff | Splinter Review
fix v0.5 (8.18 KB, patch)
2009-02-04 08:33 PST, Josh Aas
no flags Details | Diff | Splinter Review
Patch for HTML copy not including enough context for paste operations in external apps (2.17 KB, patch)
2011-08-23 12:31 PDT, Brian R. Bondy [:bbondy]
bugs: review-
Details | Diff | Splinter Review
Untested "patch" (2.55 KB, text/plain)
2012-04-27 02:52 PDT, lwz
no flags Details
Patched nsDocumentEncoder (61.43 KB, text/plain)
2012-04-27 06:10 PDT, lwz
no flags Details
Patched nsDocumentEncoder (60.61 KB, text/plain)
2012-04-29 03:55 PDT, lwz
no flags Details
Patch generated with WinMerge (7.54 KB, text/plain)
2012-04-29 03:57 PDT, lwz
no flags Details
Patch v1. (7.91 KB, patch)
2012-04-30 10:48 PDT, Brian R. Bondy [:bbondy]
bzbarsky: review-
Details | Diff | Splinter Review
Patch v2 (WinMerge output) (8.33 KB, text/plain)
2012-05-12 08:55 PDT, lwz
no flags Details
Patch v2. (8.78 KB, patch)
2012-05-12 16:32 PDT, Brian R. Bondy [:bbondy]
bzbarsky: review+
Details | Diff | Splinter Review
Base patch v3 (8.78 KB, patch)
2012-05-15 15:52 PDT, Brian R. Bondy [:bbondy]
netzen: review+
Details | Diff | Splinter Review
Fixed bug with end context not being included (4.80 KB, patch)
2012-05-15 17:27 PDT, Brian R. Bondy [:bbondy]
bzbarsky: review+
Details | Diff | Splinter Review
Fixed bug with end context not being included. v2. (4.80 KB, patch)
2012-05-15 20:52 PDT, Brian R. Bondy [:bbondy]
netzen: review+
Details | Diff | Splinter Review

Description Patrick Gade 2002-04-14 17:53:40 PDT
Hi,

When you select and copy a table in Mozilla 9.9 and then paste it into MS Excel
2000, it all appears in one cell as plain text.  However, if you first paste it
into composer and then copy and paste into Excel 2000, it pastes correctly as a
table into cells.  This problem doesn't occur in Excel 97.

For company intranets, its quite common for staff to pull out query results in
html tables and copy and paste into excel.

Off topic - it would be a really great feature to be able to select and copy
specific columns in navigator rather than just rows. eg right click->select
column as you can in composer.

Thanks.
Comment 1 R.K.Aa. 2002-04-14 18:17:20 PDT
I just copied the entire bugzilla "todays query" and pasted right into excel as
"html": Worked fine with MS Excel 2000.

Pasting as text honors first table rows onløy, however, and does not distinguish
between succeeding cells on same row.

(Build ID 2002041408 on XP)

You can select a table column bu ctrl+drag, but it will paste as a row, not
column. That's bug 76545.
Comment 2 Patrick Gade 2002-04-16 01:23:24 PDT
Created attachment 79407 [details]
example of pasting problem

I tried your example.  When I "Select All" and copy the whole page it does go
into cells fine.  However the problem occurs if I select just the table, or
just
specific rows of the table  (see attachment).  It then pastes into only one
cell (this happens
whether I choose 'paste' or 'paste special'->html. 

Thanks for the tip on using Ctrl->Drag to select a column.  I think the Table
Select context menu in composer is very good though, and might be a nice option
to add to the context menu of a table in navigator as well.

Thanks for your help.
Comment 3 Kathleen Brade 2002-05-03 08:43:59 PDT
This doesn't really sound like a selection bug to me; it sounds like a clipboard
problem.  It sounds like it works as desired in Composer.  Please clarify what
the problem is if you disagree.

-->XPApps
Comment 4 R.K.Aa. 2002-05-15 14:19:08 PDT
related to bug 69566? (122574 -> bug 92518 ->)
Comment 5 Boris Zbarsky [:bz] (TPAC) 2002-10-10 11:21:40 PDT
to DOM to Text conversion.  Note the following from bug 172424:

  "In IE, when you select the contents of a table and paste into another
   document, the cell row contents are separated with a tab. In Mozilla the cell
   row contents are separated with a space (I'm using Mozilla/5.0 (Macintosh; U;
   PPC Mac OS X; en-US; rv:1.2b) Gecko/20021009).

  "The IE behavior is rather nice because when you are pasting data from an html
   table into a spreadsheet each cell from the html table ends up in a separate
   cell in the spreadsheet, the Mozilla behavior is less useful...everything
   ends up in the first column."
Comment 6 Boris Zbarsky [:bz] (TPAC) 2002-10-10 11:22:02 PDT
*** Bug 172424 has been marked as a duplicate of this bug. ***
Comment 7 Michael Lefevre 2002-10-29 03:32:44 PST
*** Bug 154073 has been marked as a duplicate of this bug. ***
Comment 8 R.K.Aa. 2002-12-03 00:33:05 PST
*** Bug 183154 has been marked as a duplicate of this bug. ***
Comment 9 Daniel Bratell 2002-12-14 03:12:39 PST
So switching to TABs would solve this, and MSIE alread does that? I've a patch
in bug 173388 that switches to TAB and if that is a good thing, I will go look
for reviews.
Comment 10 Daniel Bratell 2002-12-14 15:52:00 PST
I think this is because when you select table contents in Mozilla and copy/paste
it the receiver get: <html><body><td>cell 1</td><td>cell2></body></html>. There
should probably be some <table> and <tr> to make everyone happy. 

The patch in 173388 inserts TABs between cells and that make it possible to, in
Excel, select "Paste Special..." from the Edit menu and then select Unicode
text, but that is probably to odd for most people to find out. 

I don't think this bug is in the right category, but I don't know which
component is responsible for creating html from a user selection when copying.
Comment 11 Alfonso Martinez 2003-02-03 12:55:45 PST
*** Bug 191782 has been marked as a duplicate of this bug. ***
Comment 12 Michael Rusignola 2003-02-07 13:13:56 PST
This is a problem for me too. If you do any amount of copy/pasting (like I do),
you'll find it crippling. Copy/Paste may work under some of the specific example
provided by R.K.Aa, but it typically does not work for me. 

I tend to select a table, and copy it then paste that into Excel. This never
works for me.
Comment 13 Steve White 2003-04-08 15:19:29 PDT
This is a problem on any OS, and any graphical spreadsheet program.
See also 181937 (Mac).  I can attest for Linux using Gnumeric, Xess, etc.

In all cases, it can be solved by putting tabs between cell contents
when copying to the clipboard.

Comment 14 Michael Rusignola 2003-05-07 16:25:19 PDT
Can we get an ETA on when this will be fixed? FYI, it's the only thing
preventing me from ditching IE altogether...
Comment 15 Michael Rusignola 2003-06-13 13:01:28 PDT
still an issue....
Comment 16 Boris Zbarsky [:bz] (TPAC) 2003-09-27 22:07:31 PDT
*** Bug 220501 has been marked as a duplicate of this bug. ***
Comment 17 Wes Morgan 2004-09-17 13:58:55 PDT
Still a problem in Firefox 1.0PR
Comment 18 David Lauri 2004-09-19 13:01:32 PDT
If Mozilla wants corporate types to switch from IE, you'd better fix this bug,
and make copying and pasting data tables work as it does in IE.  If you just
want geeks to use Mozilla, don't bother.
Comment 19 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-28 14:04:25 PST
*** Bug 272159 has been marked as a duplicate of this bug. ***
Comment 20 Bill Mason 2004-12-01 15:10:06 PST
*** Bug 272672 has been marked as a duplicate of this bug. ***
Comment 21 Jo Hermans 2004-12-03 04:17:52 PST
*** Bug 264959 has been marked as a duplicate of this bug. ***
Comment 22 Eugene Savitsky 2004-12-13 09:56:09 PST
Problem for my corporate client. Switched back to IE coz of this.
Comment 23 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-12-22 12:39:32 PST
*** Bug 247678 has been marked as a duplicate of this bug. ***
Comment 24 Hiro 2005-01-25 20:54:53 PST
*** Bug 276916 has been marked as a duplicate of this bug. ***
Comment 25 Hiro 2005-01-25 21:00:29 PST
*** Bug 276688 has been marked as a duplicate of this bug. ***
Comment 26 Urs Schmid 2005-02-09 05:25:43 PST
Hi, our problem is similar to this one, at least I think it has the same reason.
We are producing ERP software that is using browsers as client software. One of
the possibilities we have in almost all the GUI's is a search button that starts
queries for the data one is currently entering or editing. Those queries are
generating a result set displayed in a grid.
On the GUI we have an export button which allows us to print the data, export it
to files and so on. If we choose to export it in cvs format Mozilla (V 1.8b,
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050208) and
Firefox (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050208
Firefox/1.0+) do have the problem that the result is put to one cell per record
in Excel. If we use IE, it works absolutely fine.
Our prodict is written in Java and one of our best selling arguments is that we
are plattform independent. So it would be very nice if we could tell our
customers to use independent software to access our application.
Comment 27 Nathan Kirkham 2005-02-25 04:00:39 PST
I can confirm that this problem exists in Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0.

It is quite a big problem for many in our company and is one of two reasons why
we need to still use IE
Comment 28 DunxD 2005-02-25 04:08:54 PST
This bug doesn't seem to be going anywhere - still New after nearly three years.

This is a major problem, and it seemed that someone had a fix for it, but it is
still a problem, for plenty of users.

Is anything being done about this, or has it fallen of the radar of developers?
Comment 29 DunxD 2005-02-25 04:12:38 PST
I note that on sending a comment on this bug amongst the list of exclusions is
dom-to-text@mozilla.bugs.  Is that normal, or does it indicate that comments on
this bug are not making their way to people who might deal with them?
Comment 30 Bill Rowe 2005-03-04 17:22:04 PST
Several potential FireFox users have complained that this bug has existed for
years, without resolution.  I note that the reference to 173388 is probably not
meaningful anymore, since the fix for 173388 is included in the source for
FireFox 1.0.1 and the 137450 problem still exists.

Through further experimentation, I determined that I can copy from a WEB page
table to a NotePad document and then cut/paste to an Excel XP page with some 
more reasonable results (of course this loses formatting).  But at least I get
items into more than one cell.  Still the results are so far from what I need
and I expect that this knowledge would not lead to a respectable solution.  It
does, however, give a clue as to what output FireFox generates.

Perhaps the owner of this bug should follow up on the reference to 173388 and
ask the folks who understood 173388 if they have any ideas about bug 137450.  I
must admit that I'm not enough of a programmer to be able to contruct a patch in
a reasonable amount of time.  But I think the 173388 group could look at
nsPlainTextSerializer.cpp from the standpoint that both their needs and the
Excel community's needs should be met simultaneously.  Of course, I don't have
the slightest idea who dom-to-text@mozilla.bugs is.

Regards,  Bill Rowe
Comment 31 Anbo Motohiko 2005-03-18 04:59:18 PST
This is caused by missing newline after the last cell.

IE's behavour is like this ('\n' means newline, '\t' means tab):
Windows XP 55.20 \nWindows 2000 18.20 \n

Firefox (20050317)'s behavour is:
Windows XP\t55.20\n\nWindows 2000\t18.20


A Japanese friend points this out in his weblog's entry:
http://diary.noasobi.net/2005/03/diary_050317a.html

He says 'paste this to an editor, add newline after the last cell, then copy and
paste this to excel. It works well'.
Comment 32 almostbluefin 2005-04-04 11:01:36 PDT
As a non-techgeek, I have to add my vote to the legions who remain frustrated
with this bug. I'm on FireFox 1.0.2, Windows XP, and I'm a bit horrified that
it's been three years since this bug was first identified. I cut and paste
primarily from government websites, like the census, BEA and this one
http://www.st.nmfs.gov/st1/commercial/landings/annual_landings.html

They are not going to update their code anytime soon.

It is keeping me on IE for work, and these kind of temporary workaround
solutions are still more difficult than using IE, where this cut and paste works
perfectly. Anything involving intermediate steps, text editors, etc. mean fewer
people will use Firefox.
Comment 33 Ted Mielczarek [:ted.mielczarek] 2005-05-18 10:07:27 PDT
This happens because Excel chooses the HTML clipboard format over the plain text
one.  If you do Paste Special -> Plain Text, the table will paste fine.  If you
paste normally, you get HTML format, which doesn't work.  If you only select
part of a table, Mozilla doesn't put a <table> tag on the clipboard, which
screws up Excel.  Selecting the entire table (using ctrl+click on the border)
and pasting in Excel works fine.
Comment 34 Ted Mielczarek [:ted.mielczarek] 2005-05-18 13:41:59 PDT
This isn't DOM, since Excel isn't using our text/plain format.

My proposal to fix this:
Change BuildPlatformHTML to wrap the selection with the context HTML, instead of
just body and html tags.
Definition of BuildPlatformHTML:
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsDataObj.cpp#1182
Called from:
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsDataObj.cpp#886

This may require changing how the HTML info clipboard format is created, since
it currently seems to always be 0,0.  It's possible we could create a new
clipboard format, "HTML with context" or something, but that seems kind of bogus.

This is where we get the HTML fragment:
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsDocumentEncoder.cpp#1214
Comment 35 timeless 2005-05-18 13:52:50 PDT
dom-to-text@mozilla.bugs and anything like it is not a person (and does not
receive mail), it's the ability to watch a role, if you care about dom to text
bugs, then go to mail prefs:
https://bugzilla.mozilla.org/userprefs.cgi?tab=email and add that to your users
to watch list.
Comment 36 Ted Mielczarek [:ted.mielczarek] 2005-05-23 14:40:22 PDT
Added documentation on CF_HTML, showing that we don't follow the intended
implementation.  I threw together a few testcases here:
http://mavra.perilith.com/~luser/clipboardtests/

Unfortunately the results files have trailing null characters in them, so they
won't open as plain text in any recent mozilla.

It appears that we could support most of the cases without too much effort,
however IE also includes the entire contents of the HEAD tag, which might be
difficult to easily support.
Comment 37 Ted Mielczarek [:ted.mielczarek] 2005-05-30 07:18:36 PDT
Created attachment 184850 [details] [diff] [review]
Possible fix - content changes
Comment 38 Ted Mielczarek [:ted.mielczarek] 2005-05-30 07:22:48 PDT
Created attachment 184851 [details] [diff] [review]
Possible fix - widget/win32 changes

With these two patches, copying HTML to the clipboard adds a new data flavor,
"text/moz_htmlselinfo", which contains one integer indicating the offset into
the HTML context data where the selection should be inserted.  The changes to
widget/win32 changes BuildPlatformHTML so that when the CF_HTML data flavor is
requested, the HTML selection, HTML context, and the new selection info flavor
are used to provide a unified context + selection.
Comment 39 Ted Mielczarek [:ted.mielczarek] 2005-05-30 07:27:47 PDT
Just for my reference, related bugs: bug 237546 , bug 236546 

Note that this patch won't fix copying individual cells from different rows in a
table using ctrl+click.
Comment 40 Ted Mielczarek [:ted.mielczarek] 2005-06-01 07:39:04 PDT
peterv: do you know the code in nsDocumentEncoder well enough to take a look at
this, or do I have to keep looking for someone else?
Comment 41 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-06-24 22:26:05 PDT
*** Bug 298739 has been marked as a duplicate of this bug. ***
Comment 42 Frank Wein [:mcsmurf] 2005-08-03 03:56:22 PDT
*** Bug 303164 has been marked as a duplicate of this bug. ***
Comment 43 Asher 2005-08-15 10:53:26 PDT
It's been a few months that a potential patch has been available.

Has anyone tested it or know who it can be sent to for a review?
Comment 44 Ted Mielczarek [:ted.mielczarek] 2005-08-15 11:49:17 PDT
(In reply to comment #43)
> It's been a few months that a potential patch has been available.
> 
> Has anyone tested it or know who it can be sent to for a review?

I tested the patch using my testcases from comment 36.  Any other testcases for
situations I didn't cover are welcome.  I still haven't found anyone that knows
nsDocumentEncoder well enough to review.  Maybe when the 1.8 branch work winds
down I'll have better luck.
Comment 45 John 2005-09-19 07:10:31 PDT
I'd like to confirm that a CTRL-click on the table border before the copy/paste
manuver does successfully preserve formatting when moving table data from
Firefox to MS office applications (running WinXP, Firefox 1.0.6).  It's still
frustrating that IE works better for copy/paste text with formatting than Firefox.  
Comment 46 Ted Mielczarek [:ted.mielczarek] 2006-03-03 18:58:09 PST
Created attachment 213963 [details] [diff] [review]
Combined and updated to trunk

Let's see if we can't make some progress here.
Comment 47 Ted Mielczarek [:ted.mielczarek] 2006-03-03 18:59:27 PST
Also,

http://mavra.perilith.com/~luser/firefox-1.6a1.en-US.win32.zip

Current trunk build + this patch.
Comment 48 neil@parkwaycc.co.uk 2006-03-06 05:40:51 PST
Comment on attachment 213963 [details] [diff] [review]
Combined and updated to trunk

>+  NS_IMETHOD EncodeToStringWithContextExtra(nsAString& aEncodedString, 
I think it would be better if you added the extra info to the info string (duh), and fixed up the existing consumer (nsHTMLEditor::CreateDOMFragmentFromPaste in nsHTMLDataTransfer.cpp).
Comment 49 Ted Mielczarek [:ted.mielczarek] 2006-03-13 12:04:21 PST
Ugh, after a little more testing, it turns out that this patch works except if you select one table cell, in which case Excel will not paste anything.  Looks like I need to do some more work...

I'll attach an updated patch shortly anyway, but it's not ready to go yet.
Comment 50 Cameron 2006-03-21 20:59:05 PST
*** Bug 331289 has been marked as a duplicate of this bug. ***
Comment 51 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-05-17 08:09:11 PDT
*** Bug 338270 has been marked as a duplicate of this bug. ***
Comment 52 oliver corlett 2006-07-28 08:43:43 PDT
A problem, perhaps related?, with copy/pasting from web pages to Excel. It began to happen after one of the new Firefox releases a couple months ago. Sorry I can't remember which one.
Here's an example:
Go to: http://finance.yahoo.com/q/bs?s=ASX&annual
Copy the row beginning "Cash and Cash Equvalents"
Paste it into Excel

The first cell in the row is fine, but the second looks like this:
406,290ash And Cash Equivalents, 
and the real first cell is pushed over to the right by one cell

This never used to happen on the earlier release. It's not a huge deal, but would be nice if someone could fix it.

I'm using Excel 97, and XP
Comment 53 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-09-26) 2006-08-15 07:05:59 PDT
FWIW, when the Windows CF_HTML generation code is used on Mac (bug 332912), the same brokenness is manifested with Mac Office (not surprisingly).
Comment 54 Will Budreau 2006-10-30 17:31:26 PST
Same problem applies when trying to copy a table and paste into the MS Outlook or Word mail composers.
Workaround of selecting before the start of the table works for me.
Comment 55 John M. Black 2007-01-20 07:38:40 PST
Someone mentioned this was being tested for 1.6?  Not sure if I misinterpreted that.  In any case, FF 2.0.0.1 still has this problem (for me, anyway;) even selecting before the start of the table doesn't work.  I'm on a project which has be copying lots of stuff into Excel for the next few weeks, and I'm sorry to say I had to switch back to IE.
Comment 56 Ted Mielczarek [:ted.mielczarek] 2007-01-20 08:33:34 PST
John:  Unfortunately this patch had some problems, so I wasn't able to finish it in that timeframe.  Hopefully I will find the time and get this in for Firefox 3.
Comment 57 Matthias Versen [:Matti] 2007-12-20 05:47:54 PST
*** Bug 397932 has been marked as a duplicate of this bug. ***
Comment 58 Josh Aas 2009-02-04 08:33:55 PST
Created attachment 360522 [details] [diff] [review]
fix v0.5

Ted's last patch updated to current trunk, doesn't work but might be a helpful starting point.
Comment 59 RNicoletto 2009-02-06 05:57:40 PST
Possible workaround: Table2Clipboard extension (https://addons.mozilla.org/firefox/addon/1852).
Comment 60 Ted Mielczarek [:ted.mielczarek] 2009-02-06 06:10:24 PST
Josh: it looks like my latest patch didn't actually include the widget changes (not sure why). attachment 184851 [details] [diff] [review] is also necessary to make this fix work on Windows. The BuildPlatformHTML function does most of the work, you could probably uplift that into the Core and just use it from each widget implementation. Note that the Win32 widget code does want to know the length of each particular string, and needs to stick specific HTML comments in to indicate the beginning/end of the selection.
Comment 61 Josh Aas 2009-03-05 13:07:25 PST
*** Bug 470384 has been marked as a duplicate of this bug. ***
Comment 62 Josh Aas 2009-03-05 13:09:51 PST
Gecko now exposes HTML to the native clipboard on Mac OS X, and as a result this bug was exposed on Mac OS X. Due to the way Excel handles pulling data from the native clipboard, some row-splitting behavior is regressed. See bug 470384, which is now a duplicate of this bug.
Comment 63 Mike Beltzner [:beltzner, not reading bugmail] 2009-03-10 11:49:03 PDT
Not blocking, but if you get the patch with tests baked we'd take it before code freeze at the end of the month.
Comment 64 Kevin Brosnan 2009-08-22 11:04:09 PDT
*** Bug 512068 has been marked as a duplicate of this bug. ***
Comment 65 Kevin Brosnan 2009-08-22 11:05:10 PDT
*** Bug 504671 has been marked as a duplicate of this bug. ***
Comment 66 juan becerra [:juanb] 2009-09-25 10:26:46 PDT
*** Bug 504671 has been marked as a duplicate of this bug. ***
Comment 67 philibert 2009-10-13 15:34:08 PDT
Any news on the last patch that was submitted? I can't complain as I can't develop, but I check this bug's status after each release. It has been reported more than 7 years ago.
Comment 68 Kevin Brosnan 2009-11-21 22:11:38 PST
*** Bug 504671 has been marked as a duplicate of this bug. ***
Comment 69 Smokey Ardisson (offline for a while; not following bugs - do not email) 2009-11-29 22:34:04 PST
*** Bug 504671 has been marked as a duplicate of this bug. ***
Comment 70 Paul Bailey 2009-11-30 17:53:30 PST
Since Bug 504671 has been marked as a duplicate of this it is worth pointing out what that related bug is.

When you copy and paste a portion of a table from other browsers, the content is not marked as HTML, but FF 3.5 (this is a regression, not a problem in 3.0) includes a HTML type on the clipboard. This breaks the once working functionality.

Safari does a more logical thing and only uses plain text / rich text for this type of data. who could complain about a table being represented as having tabs between it? If you copy a whole table, then i could see the complaint, but a portion?

Kevin Brosnan writes at but 504671, "Till (sic) Excel can handle pasting partial table data or code is written to fix bug 137450 use one of the following." 

But I think it would be more through to say that Excel would have to be able to handle malformed HTML because the current "Apple HTML pasteboard type" (the problem causer) does not open or close a table tag, nor does it open or close a tr tag, just has raw td tabs. Why not just force table and tr tags?
Comment 71 Paul Bailey 2009-11-30 17:54:01 PST
It is also worth pointing out that the raw td tags can have classes that are not defined. These classes in the td tag should either be removed or their definitions included. What possible meaning is there to including them without definitions? what could a parser possibly do with that except deal with the buggy missing class definition? Why stress the other code that way?
Comment 72 Jazznme2 2009-12-18 19:05:01 PST
I just want to copy/paste, into EXCEL, short phrases, statements, or numerical data.....like I could before this 3.5. This is so____. I'm not pasting a whole chart!! or columns.
Maybe a recipe. PLEEEEEZ somebody HelP!!!!!
Comment 73 Charley Kyd 2009-12-19 20:24:08 PST
We've been able to copy and paste tabular data from IE to Excel from day one. We also can do so with Chrome and Safari. 

I'm amazed that Mozilla has ignored this bug for more than seven years.

There are 400 million Excel users in the world. About a hundred thousand of them visit my site every month. I, for one, will be telling them that Firefox isn't Excel friendly.

Charley Kyd
ExcelUser.com
Comment 74 RNicoletto 2009-12-21 05:28:44 PST
(In reply to comment #73)
> There are 400 million Excel users in the world. About a hundred thousand of
> them visit my site every month. I, for one, will be telling them that Firefox
> isn't Excel friendly.
> 

As per comment 59 you should tell your site visitors that Firefox + Table2Clipboard extension are a perfect companion for Excel users.
Comment 75 philibert 2009-12-21 06:38:36 PST
I'm not sure this is the place to have this discussion, and I apologize if it's not, but:
- As said functionality works out of the box with all other browsers (it even worked with very early versions of Chrome), I believe users expect it to work in FF as well without a plugin. So from an end-user perspective, this is a bug.
- If Table2Clipboard does manage it well, why not include its behavior in FF directly?
- I must be totally dumb, but I still can't figure out how to use Table2Clipboard properly.

Finally, there is a proposed fix. I didn't check it, I don't know the procedures, but it seems to me that having a look at the fix, at Chrome's implementation and pushing this for the next release should not take much more time than discussing this here and marking new bug reports as duplicate.

Again, sorry to be the end-user with no coding skills complaining about an otherwise outstanding product.
Comment 76 Paul Bailey 2009-12-21 07:07:58 PST
(In reply to comment #74)
> (In reply to comment #73)
> > There are 400 million Excel users in the world. About a hundred thousand of
> > them visit my site every month. I, for one, will be telling them that Firefox
> > isn't Excel friendly.
> > 
> 
> As per comment 59 you should tell your site visitors that Firefox +
> Table2Clipboard extension are a perfect companion for Excel users.

Not perfect (1) it is not "out of the box" functionality, so it requires knowledge of how to install addins and comfort allowing them and managing them. (2) Table2Clipboard requires that you can control click which is a right click on a Apple laptop. See comments at Bug 504671.
Comment 77 Matthias Versen [:Matti] 2010-05-31 08:38:58 PDT
*** Bug 569200 has been marked as a duplicate of this bug. ***
Comment 78 PhistucK 2011-03-06 02:32:36 PST
This reproduces in FireFox 4b12.
Go to about:support, select the Hardware Acceleration table at the bottom, press Ctrl+C, open Notepad, press Ctrl+V - One line of text with no spaces between the cells/new lines between the rows.
Related/duplicated issues -
https://bugzilla.mozilla.org/show_bug.cgi?id=638439
https://bugzilla.mozilla.org/show_bug.cgi?id=572543
https://bugzilla.mozilla.org/show_bug.cgi?id=237546
https://bugzilla.mozilla.org/show_bug.cgi?id=303736
https://bugzilla.mozilla.org/show_bug.cgi?id=515464
Comment 79 Brian R. Bondy [:bbondy] 2011-08-23 12:31:56 PDT
Created attachment 555160 [details] [diff] [review]
Patch for HTML copy not including enough context for paste operations in external apps

This patch fixes copy HTML operations in Firefox and hence also fixes paste operations in:
Word, Excel, Firefox and other programs for partial table selection.

This also fixes things like pasting only a couple of <li> items when they belong to an <ol>.  
Pasting them before would result in bullet points, but pasting them now results in a numbered partial list.

The problem was with the HTML range selection not including enough context.  
We should include parent items (and their attributes) for items like <tbody>, <tr>, <li>, ...

The fix was simply to change the common ancestor code to determine a common ancestor which provides enough context when one like <tbody> was the common ancestor.
Comment 80 Brian R. Bondy [:bbondy] 2011-08-23 12:36:20 PDT
*** Bug 638439 has been marked as a duplicate of this bug. ***
Comment 81 Brian R. Bondy [:bbondy] 2011-08-23 12:41:12 PDT
*** Bug 303736 has been marked as a duplicate of this bug. ***
Comment 82 Olli Pettay [:smaug] (TPAC) 2011-08-24 04:40:15 PDT
Comment on attachment 555160 [details] [diff] [review]
Patch for HTML copy not including enough context for paste operations in external apps

You can't change nsContentUtils::GetCommonAncestor this way.
nsContentUtils::GetCommonAncestor is used in many places and it is expected to
return the common ancestor, not something else.
Comment 83 Brian R. Bondy [:bbondy] 2011-08-24 04:53:04 PDT
Sorry I meant to ask specifically about it in the attachment comment and if I should create a similarily named function.  Ill submit a new patch with that change.
Comment 84 Michael Newton 2011-11-24 20:39:00 PST
Seems like a pretty straightforward bug with a tiny little patch. Did this just drop off the radar?
Comment 85 Brian R. Bondy [:bbondy] 2011-11-27 08:32:45 PST
> Seems like a pretty straightforward bug with a tiny little patch. 
> Did this just drop off the radar?

I probably won't have time to get back to this for a month or two, if someone else wants to pick it up in the meantime please feel free.  If not I'll get back to it eventually :)
Comment 86 Charley Kyd 2011-11-27 10:00:26 PST
Firefox is the only browser I've found that has this problem. IE, Chrome, Opera, and Safari do not. 

You've been discussing the issue for more than nine years. This is ridiculous.
Comment 87 Charley Kyd 2011-11-27 10:01:03 PST
Firefox is the only browser I've found that has this problem. IE, Chrome, Opera, and Safari do not. 

You've been discussing the issue for more than nine years. This is ridiculous.
Comment 88 Brian R. Bondy [:bbondy] 2011-11-27 12:02:01 PST
Thanks Charley Kyd, I agree it's been too long. I am currently finishing a large project, but I personally do want to see this fixed as well so I will get to it sooner if I can.
Comment 89 RNicoletto 2012-01-17 02:59:45 PST
*** Bug 673802 has been marked as a duplicate of this bug. ***
Comment 90 lwz 2012-04-25 00:36:50 PDT
Please resolve this problem; it's really a big issue. Using FreeClipViewer I managed to gather that Firefox only copies the <tr>s and <td>s as the HTML fragment and does not surround that fragment with a <table> and <tbody> tag. Is it really difficult to test if the selection is *inside* a table and just surround the HTML fragment with the corresponding <table> and <tbody> tags?
Comment 91 lwz 2012-04-25 00:42:26 PDT
Also, there is already some code to almost implement the behavior above, which happens when you select from inside a table to outside the table. In that case, the <table> and <tbody> tags get placed into the HTML fragment instead of surrounding it, which is logical.
Comment 92 :Ehsan Akhgari 2012-04-25 20:00:01 PDT
Brian, have you had a chance to take a look at this?
Comment 93 Brian R. Bondy [:bbondy] 2012-04-26 00:14:38 PDT
Sorry I haven't had a chance to pick this up again. I had to re-prioritize since Comment 88.  Realistically I still have a few security bugs and a snappy bug to do on the portion of my time available outside of the main project work.  To anyone who can pickup before I get back to it, please feel free to steal.
Comment 94 lwz 2012-04-26 03:14:24 PDT
I can see if I can help; but that is if I can understand the code first... Where's the place in the code that implements the HTML selection copying? I'm thinking of looking it up in http://mxr.mozilla.org instead of downloading the whole code.
Comment 95 John 2012-04-26 04:38:06 PDT
Hi,

I have Firefox 12.0 and Excel 11.6.2 om a MacPro using Snowleopard

I, too, have the same problem described here with a simple Paste.

However, I am able to copy and paste entire tables into separate cells with this workaround:

--Highlight area of Foxfire table I wish to copy.
--Copy it.
--Highlight destination cell in Excel.
--Select 'Paste Special'.
--Select 'Unicode Text'.
--Click 'OK'

two extra keystrokes...

Works every time. 

I do it daily from several sites which have my checking and Mastercard purchases listed in table form, or any web table I want to import into Excel.
Comment 96 :Ehsan Akhgari 2012-04-26 11:47:21 PDT
(In reply to lwz from comment #94)
> I can see if I can help; but that is if I can understand the code first...
> Where's the place in the code that implements the HTML selection copying?
> I'm thinking of looking it up in http://mxr.mozilla.org instead of
> downloading the whole code.

The main function involved in copying something from an HTML document is SelectionCopyHelper <http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsCopySupport.cpp#106>.  If you want to debug this, it's best to set a breakpoint there, and then follow the execution to this SetData call <http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsCopySupport.cpp#287> which is what puts the copied data on the clipboard.

Please let me know if you need help finding some code involved here.  :-)
Comment 97 lwz 2012-04-26 19:14:07 PDT
I have taken a look, and was just thinking if we could just add table and tr tags to the list in the IncludeInContext function at http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocumentEncoder.cpp#1487

What do you think?
Comment 98 lwz 2012-04-26 19:30:57 PDT
Oh ignore that... just realised it will not work.
Comment 99 lwz 2012-04-27 01:22:30 PDT
Is it wise to change SerializeRangeToString or will it affect other XML documents that happen to use table/tr/td tags as well? Or I could create a copy of SerializeRangeToString and name it to SerializeSelRangeToString just for use in the "if (mSelection) {" branch of nsDocumentEncoder::EncodeToString.
Comment 100 lwz 2012-04-27 01:54:43 PDT
Ok. I think I know what we can do. We can add nsHTMLCopyEncoder versions of SerializeRangeContextStart and SerializeRangeContextEnd like what was done already for the IncludeInContext. Sorry for the many earlier tries - I was getting orientated.
Comment 101 lwz 2012-04-27 02:52:39 PDT
Created attachment 618965 [details]
Untested "patch"

Totally untested "patch". I don't have the time to download and compile the code yet. Hope someone can do that for me. I also am absolutely unfamiliar with the patch submission process, so bear with me.
Comment 102 lwz 2012-04-27 03:31:22 PDT
Anyway for the meantime, the best solution I found was to copy the selected cells to an empty HTML editor in Firefox like the Gmail compose window, select all, and copy. Hope this helps for the other users.
Comment 103 lwz 2012-04-27 03:34:13 PDT
But the above only works if you're not selecting ranges of cells using the Ctrl.
Comment 104 Ted Mielczarek [:ted.mielczarek] 2012-04-27 05:24:18 PDT
If you click "show obsolete" on the attachments table here, you can see some 6-year-old patches I had that were a potential fix: attachment 184850 [details] [diff] [review] and attachment 184851 [details] [diff] [review]. I'm sure they're quite out of date now, but the core concepts probably still work.
Comment 105 lwz 2012-04-27 05:50:17 PDT
@Ted: Could you explain what the core concept for your patch is? It is really very different. But I was hoping someone could try out my patch, which I believe will work. The reason why the table is not pasting properly is that the table and tr tags were not included in the fragment. Ideally, they should be *outside* the fragment, but in this case I put them inside, following the same idea as Brian. This is because I do not want to change http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsDataObj.cpp#1833, which is all hard-coded (*gulps*)!
Comment 106 lwz 2012-04-27 06:10:34 PDT
Created attachment 619005 [details]
Patched nsDocumentEncoder

I'm trying to make it easier for someone to test my "patch".
Comment 107 Ted Mielczarek [:ted.mielczarek] 2012-04-27 06:24:54 PDT
It's been a while, but IIRC, the existing code in nsHTMLCopyEncoder builds a "context" string that it puts on the clipboard with a different data flavor. This string is just the stack of HTML tags from the context up through and including the selection. My patch made that code save some extra data pointing to where the context ended and the selection began in that string, so then the Windows BuildPlatformHTML code could extract the actual context tags to wrap around the selection.

It looks like bbondy's attachment 555160 [details] [diff] [review] took a different approach and modified the GetCommonAncestor code to return more context in certain circumstances.
Comment 108 Brian R. Bondy [:bbondy] 2012-04-27 06:51:09 PDT
Looking back I think that Ted's way is better.  There is documentation on the HTML format here by the way:
http://msdn.microsoft.com/en-us/library/aa767917%28v=vs.85%29.aspx
Comment 109 lwz 2012-04-27 07:19:05 PDT
Actually, from what I gather, the string that the nsHTMLCopyEncoder generates does not generate the table/tr tags where necessary. It does not output any tr tag when the selection spans the tds of a single row or any table tag when the selection spans the trs of a table. That's the issue I'm solving.
Comment 110 lwz 2012-04-27 07:58:00 PDT
However do I generate a patch file without having to download the *entire* repository!?
Comment 111 Brian R. Bondy [:bbondy] 2012-04-27 08:34:25 PDT
It would be best to download mozilla-central source code and then compile your patch to make sure it works.  You can get the source code here:
https://developer.mozilla.org/en/Mozilla_Source_Code_%28Mercurial%29

If you have any build specific questions I would be happy to help on IRC, just message bbondy, or email me, or you can ask in the bug.
Comment 112 lwz 2012-04-28 00:39:58 PDT
Hi everyone, I have no machine here which is capable of this huge CPU-intensive operation -- I've downloaded the hg bundle, and I estimate (after running it for a while) that it will take more than 3 hours just to unbundle, and another few hours to compile. Would appreciate anyone having the time and computing power to just test this patch for me. I'm not a hard-core developer, and just happened to come across this irritating bug. Feel free to steal this bug and my patch from me; just post a message indicating your intention. Sorry Brian.
Comment 113 Brian R. Bondy [:bbondy] 2012-04-28 09:58:39 PDT
So if I understand your patch correctly then I think it will not work because you will put a table around every table data cell that is copied.  I tried something similar when I did it but just by modifying the already virtual IncludeInContext.  Let me know if I did not understand your code though. 

I did try it as well and it did not compile because virtual should not be in the definition, just the declaration.  After that it crashes because 
nsCOMPtr<nsIContent> content(do_QueryInterface(node)); can sometimes and is sometimes NULL.  After that it gave as I mentioned above.
Comment 114 lwz 2012-04-29 01:10:33 PDT
Oh yes, you will be right about that. Sorry, I didn't realize that. But at the very least it should solve the case where you are selecting cells without using Ctrl. There's no avenue to do have done this partial patch from within IncludeInContext because then *all* the ancestors that are table-related will appear, whereas if you do this in SerializeRangeContextStart/End you will be able to check if it's the immediate parent. So that's what I did. To make it work with Ctrl, I would probably have to edit the part where the patch for "Bug 236546" is, and somehow disable the portion in SerializeRangeContextStart/End. I will think about this and get back. Will try not to make silly errors like the last one. If you have the "patched" version you could help to verify that if you select without using Ctrl it pastes correctly. Thanks.
Comment 115 lwz 2012-04-29 03:55:21 PDT
Created attachment 619379 [details]
Patched nsDocumentEncoder

I corrected the bugs and added code to cater for multiple td selections when using Ctrl to highlight cells. I assume that p->GetNodeParent will not completely fail when p is already a tr element. If it returns nsnull, I assume that passing a null node to nsContentUtils::GetAncestors will not fail, but just give me an empty list (which it currently should do, according to its source code). Let me know if I need to put in an extra temporary variable to check this (in case the implementation of nsContentUtils::GetAncestors changes).

I also use a new boolean member called mNoContext, which I reset to false every time after use.
Comment 116 lwz 2012-04-29 03:57:30 PDT
Created attachment 619380 [details]
Patch generated with WinMerge

This is the patch generated by WinMerge.
Comment 117 lwz 2012-04-29 05:37:38 PDT
For info, I found that Chrome also uses the same "fix" for partial tables. It puts the table tag inside the HTML fragment. However, I agree that Ted's method might be a bit more helpful in the long run. But I can't tell what goes wrong with his patch when you select just one table cell (see Comment 49). We need to see what is actually put on the clipboard by Firefox using FreeClipViewer or some other software. I believe it might be fixed simply by removing the first element of mCommonAncestors (a tr) at this point: http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocumentEncoder.cpp#1109, before EncodeToStringWithContextExtra takes mCommonAncestors, so that the tr would not be nested inside another tr.
Comment 118 Brian R. Bondy [:bbondy] 2012-04-30 10:48:46 PDT
Created attachment 619614 [details] [diff] [review]
Patch v1.

Thanks for the patch!

This new patch provided by lwz seems to work correctly.  The raw HTML format viewed by using clipspy.exe seems to look correct and pasting to Excel works. 

Marking ehsan for review on lwz's behalf.  I will implement any review comments but keep the author as lwz.
Comment 119 :Ehsan Akhgari 2012-04-30 11:09:47 PDT
So, you didn't set the review request.  But I guess bz is a better reviewer here.
Comment 120 Brian R. Bondy [:bbondy] 2012-04-30 11:12:01 PDT
Comment on attachment 619614 [details] [diff] [review]
Patch v1.

Marking bz for review on behalf of lwz as per ehsan's suggestion
Comment 121 lwz 2012-05-01 08:07:21 PDT
Thanks for the help.

There's also another bug with EncodeToStringWithContext regarding the usage of mCommonAncestors, mStartDepth and mEndDepth to fill the data object with HTML context and HTML info. This was already present with both IncludeInContext and the other bug fix, so I also didn't adjust these three variables correctly in my patch. I think it should be put into a separate bug because it involves fixing IncludeInContext and the other bug fix too, or maybe changing the way these things are handled in the first place. But I don't really know the impact as I am unclear how mStartDepth and mEndDepth are really used in the pasting code (http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/html/nsHTMLDataTransfer.cpp#2216). I will look at it some other time.
Comment 122 lwz 2012-05-01 08:12:37 PDT
But logically, having a mStartDepth and mEndDepth smaller than the correct values shouldn't affect the paste, and I don't think it is essential for the HTML context to be correct (currently). Therefore, this patch should be OK for the time being.
Comment 123 Brian R. Bondy [:bbondy] 2012-05-08 06:16:18 PDT
Thanks lwz. If you think this is a problem in general please post another bug for that. It seems to me like your patch is still good and ready for review.
Comment 124 lwz 2012-05-08 22:20:44 PDT
Yes I was actually also expecting review still.
Comment 125 Boris Zbarsky [:bz] (TPAC) 2012-05-11 22:49:58 PDT
Comment on attachment 619614 [details] [diff] [review]
Patch v1.

Sorry for the lag here; I had to sort out how this code works...

>+++ b/content/base/src/nsDocumentEncoder.cpp
>+  bool              mNoContext;  

This should be documented.  And perhaps named mSkipContextWhenSerializingRange.

>@@ -1081,40 +1083,60 @@ nsDocumentEncoder::EncodeToString(nsAStr
>         nsCOMPtr<nsIContent> content = do_QueryInterface(node);
>         if (content && content->Tag() == nsGkAtoms::tr) {
>           nsCOMPtr<nsINode> n = do_QueryInterface(node);

You didn't write this code, but...

  nsINode* n = content;

And the content->Tag() == nsGkAtoms::tr should probably be:

  content->IsHTML(nsGkAtoms::tr)

>+nsHTMLCopyEncoder::SerializeRangeContextStart(const nsTArray<nsINode*>& aAncestorArray,

I'm not all that happy wih the duplication of code between this method and the superclass.  Maybe factor the common code out into a method that has an extra integer argument and pass 'j' from here but 0 from the superclass SerializeRangeContextStart?

>+    if (!content || content->Tag() != nsGkAtoms::tr    &&
>+                    content->Tag() != nsGkAtoms::thead &&
>+                    content->Tag() != nsGkAtoms::tbody &&
>+                    content->Tag() != nsGkAtoms::table)

What about tfoot?  Also, should check for !content->IsHTML().

>+nsHTMLCopyEncoder::SerializeRangeContextEnd(const nsTArray<nsINode*>& aAncestorArray,

Similar comments here.  But why are we using a boolean flag here and an int in SerializeContextStart()?  It'd be clearer that they're equivalent if they used the same setup. In particular, you could move determination of 'j' into a helper method to make it clearer what's going on.

r- but a review on the updated patch should happen much faster now that I'm more familiar with this stuff.
Comment 126 lwz 2012-05-12 08:55:06 PDT
Created attachment 623435 [details]
Patch v2 (WinMerge output)

Here's an updated version. It has not been tested, but you might want to see if the way it's being done is alright.

I'm not comfortable with such extremely long variable names, so mNoContext is now called mContextAlreadySerialized, with some comments.

I get the index of the node that the immediate context starts with a helper function, though it might be slower that way. I've also added more comments here and there.
Comment 127 Brian R. Bondy [:bbondy] 2012-05-12 13:37:27 PDT
Comment on attachment 623435 [details]
Patch v2 (WinMerge output)

I'll clean this up a bit over the weekend and request a review from bz on lwz's behalf.  Thanks for the updates lwz.
Comment 128 Brian R. Bondy [:bbondy] 2012-05-12 16:32:01 PDT
Created attachment 623464 [details] [diff] [review]
Patch v2.

Thanks again for quickly addressing the review comments lwz.
Fixed some coding sytle related things.  The patch compiled as you provided it and still works with pasting individually selected cells to Excel.
Comment 129 Boris Zbarsky [:bz] (TPAC) 2012-05-15 11:47:23 PDT
Comment on attachment 623464 [details] [diff] [review]
Patch v2.

This is much better!

Two nits:

1)  Please rename GetImmediateContextIndex to GetImmediateContextCount, have it return j and 0 instead of j-1 and -1 respectively, and change the <= to < in the SerializeRangeContextStart/End loops.  That would make it clearer what's going on woth the immediate context, I think.

2)  Hoist the mContextAlreadyserialized checks above the array length gets in SerializeRangeContextStart/End, please.

r=me with those.  Thanks for the patch!
Comment 130 Brian R. Bondy [:bbondy] 2012-05-15 12:07:37 PDT
I'll fix the nits and see it to landing, thanks so much for the contribution lwz!
Thanks for the review bz.
Comment 131 Brian R. Bondy [:bbondy] 2012-05-15 15:52:10 PDT
Created attachment 624223 [details] [diff] [review]
Base patch v3

Implemented nits.
Comment 132 Brian R. Bondy [:bbondy] 2012-05-15 17:27:40 PDT
Created attachment 624255 [details] [diff] [review]
Fixed bug with end context not being included

Pasting to excel worked, but I looked at the clipboard output before landing and noticed there was no ending context.  This patch fixes it.
Comment 133 Boris Zbarsky [:bz] (TPAC) 2012-05-15 19:27:16 PDT
Comment on attachment 624255 [details] [diff] [review]
Fixed bug with end context not being included

r=me
Comment 134 lwz 2012-05-15 19:41:29 PDT
Thanks for that bug correction! I didn't realise that that would happen with shifting that reset outside the if-loop :O
Comment 135 lwz 2012-05-15 19:58:51 PDT
Sorry, I think we should also change line 1146 (mDisableContextSerialize = false;) to be above the SerializeRangeContextEnd -- my same mistake. The code at that point will be run when you select a table cell range with Ctrl, then continue the multiple selection by selecting something else outside the table (that is not in a table), with Ctrl held down, and then copy.
Comment 136 Brian R. Bondy [:bbondy] 2012-05-15 20:12:14 PDT
Oops ya I'll include that as well.
Comment 137 Brian R. Bondy [:bbondy] 2012-05-15 20:52:56 PDT
Created attachment 624293 [details] [diff] [review]
Fixed bug with end context not being included. v2.

Carrying forward r+.

Tested with ctrl + select table cells + text and could reproduce the missing end tags.  After applying the v2 patch this works properly.
Comment 138 Brian R. Bondy [:bbondy] 2012-05-15 21:06:15 PDT
Pushed to try, if all tests pass I'll push this out tomorrow.

Note You need to log in before you can comment on or make changes to this bug.