Chrome 54 Only : Table Border is lost when copied a table from Sheets to compose window |
||||||||||||||||||
Issue descriptionENV : Build [gmail_fe_161018.00_p1] OS [Win 08] Browser [Chrome 54] Account [vijendrap@google.com] Repro Steps: 1) Open Sheets 2) Create a table with some data and include some borders ex : copy the table from here : https://docs.google.com/spreadsheets/d/1OrvMMnstCzW9IR7bUczFwovKVP6Liddx6IoqivAvHN0/edit#gid=254278460&vpid=A4 3) Paste the table in Compose and observe Actual Result: Table Border is lost Screen Shot : https://screenshot.googleplex.com/AdvN6sHVR8X Expected Results : Table Border needs to be retained Screen Shot:https://screenshot.googleplex.com/fjzHV0EsWUD
,
Oct 28 2016
,
Oct 28 2016
Able to reproduce the issue on windows-7, Win-10, Mac 10.11.6 and Linux Ubuntu-14.04 using chrome stable version 54.0.2840.71 and canary 56.0.2903.0 This is regression issue broken in M54.Please find the bisect information as below Narrow Bisect:: =============== Good :54.0.2789.0 -- (build revision 403806) Bad:: 54.0.2789.0 -- (build revision 403806) ChangeLog: ================ https://chromium.googlesource.com/chromium/src/+log/b9999d69a942ce4d7caad87bd5cadddcea313779..fa2d2a6106a343fdeb317926fd9dbd1d00df4a52 Possible suspect ================== 8ebfae3567b1bfe350286345bb0c338b9f354fe1 Review URL:https://codereview.chromium.org/2121613003 dominicc@ could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue. Thanks,
,
Oct 28 2016
Typo on above Narrow Bisect Good :54.0.2789.0 -- (build revision 403806) Bad:: 54.0.2790.0 -- (build revision 404030)
,
Oct 31 2016
,
Nov 1 2016
Hey Dominic, Are you able to take a look at this issue? Thanks!
,
Nov 2 2016
Paste into data:text/html,<div contenteditable></div> and inbox composer work as expected on M54 and M56 canary. It seems Gmail specific issue?
,
Nov 3 2016
Hi Yosin, Please see more details about the issue in b/32325581. The issue doesn't repro on any other browsers, also doesn't repro in Chrome 53. But it repros with oldest Gmail Build we had available at the time "gmail_fe_160913.00_p2". Thanks!
,
Nov 15 2016
I can reproduce this. This may be related to that change but I'm not sure. I could try reverting it and see if it changes. Here's an observation: If I create a table with black external border and paste it into data:text/html,<body contenteditable> then the borders look right; if I paste them into Gmail the borders look wrong. I wonder if something is going on with the border-collapse or border-spacing from the surrounding content in Gmail.
,
Dec 14 2016
Hi All, Any udates on this Bug, this issue is reproducible on Chrome 55 as well. Thanks !
,
Dec 15 2016
Could someone from the style team help me out with this? Could you follow the repro instructions above and tell me where one of the pasted TDs computed border-(t|l|b|r)-style properties gets "inset" from?
Gmail peeps, I did some more digging:
Here's what sheets puts on the clipboard for a table with black borders:
<meta http-equiv="content-type" content="text/html; charset=utf-8"><meta name="generator" content="Sheets"><style type="text/css"><!--td {border: 1px solid #ccc;}br {mso-data-placement:same-cell;}--></style><table cellspacing="0" cellpadding="0" dir="ltr" border="1" style="table-layout:fixed;font-size:13px;font-family:arial,sans,sans-serif;border-collapse:collapse;border:1px solid #ccc"><colgroup><col width="120"></colgroup><tbody><tr style="height:21px;"><td style="padding:2px 3px 2px 3px;vertical-align:bottom;background-color:#9fc5e8;border-top:1px solid #000000;border-right:1px solid #000000;border-bottom:1px solid #000000;border-left:1px solid #000000;" data-sheets-value="{"1":2,"2":"I am"}">I am</td></tr><tr style="height:21px;"><td style="padding:2px 3px 2px 3px;vertical-align:bottom;border-right:1px solid #000000;border-bottom:1px solid #000000;border-left:1px solid #000000;" data-sheets-value="{"1":2,"2":"a fancy"}">a fancy</td></tr><tr style="height:21px;"><td style="padding:2px 3px 2px 3px;vertical-align:bottom;border-right:1px solid #000000;border-bottom:1px solid #000000;border-left:1px solid #000000;font-style:italic;" data-sheets-value="{"1":2,"2":"table"}">table</td></tr></tbody></table>
Here's some interesting parts:
(1): <style type="text/css"><!--td {border: 1px solid #ccc;}...--></style>
<table cellspacing="0" cellpadding="0" dir="ltr" border="1" style="table-layout:fixed;...;border-collapse:collapse;border:1px solid #ccc">
...
<td style="padding:2px 3px 2px 3px;vertical-align:bottom;background-color:#9fc5e8;(2) border-top:1px solid #000000;border-right:1px solid #000000;border-bottom:1px solid #000000;border-left:1px solid #000000;" data-sheets-value="{"1":2,"2":"I am"}">I am</td></tr>
...
Here's what ends up in the DOM:
<table cellspacing="0" cellpadding="0" dir="ltr" border="1" style="table-layout: fixed; font-size: 13px; font-family: arial, sans, sans-serif; border-collapse: collapse; border: 1px solid rgb(204, 204, 204);"><colgroup><col width="120"></colgroup><tbody><tr style="height: 21px;"><td style="padding: 2px 3px; vertical-align: bottom; background-color: rgb(159, 197, 232); (3) border-color: rgb(0, 0, 0);">I am</td></tr><tr style="height: 21px;"><td style="padding: 2px 3px; vertical-align: bottom; border-right-color: rgb(0, 0, 0); border-bottom-color: rgb(0, 0, 0); border-left-color: rgb(0, 0, 0);">a fancy</td></tr><tr style="height: 21px;"><td style="padding: 2px 3px; vertical-align: bottom; border-right-color: rgb(0, 0, 0); border-bottom-color: rgb(0, 0, 0); border-left-color: rgb(0, 0, 0); font-style: italic;">table</td></tr></tbody></table>
When I paste into Gmail, I actually see a brief flash of style which does include table borders.
Here's what I think happened here:
Chrome changed in 8ebfae3567b1bfe350286345bb0c338b9f354fe1 to include that style tag (1). This changed things which is why you're seeing this now. No argument there. Pasting the style tag is intended.
It appears Gmail is doing some style rewriting of its own, and it is rewriting the border-(top|left|bottom|right) rules (2) from 1px solid #000000; to be just colors (for example, border-color: rgb(0, 0, 0), (3).) Which is very clever, except...
It appears (in inspector, looking at computed styles) that Chrome now computes the border style for those cells to be 'inset'. (Style people, halp? Where does that come from?)
A fix that you could do on the server side is not have Gmail delete 'solid' from the border-* inline style rules on the TDs.
,
Jan 16 2017
meade, could you help me find someone on the style team who can dig through why Chrome computes the some particular border styles (see the repro and comment 12) as "inset"?
,
Jan 16 2017
As a starting point for someone to look into this, I'd guess it's from HTMLTableElement::createSharedCellStyle(), which adds CSSValueInset when getCellBorders() is InsetBorders (I didn't double check in a debugger though).
,
Jan 16 2017
vijendrap: could you consider changing Gmail's pasted content rewriting to set a rules="all" attribute, or a bordercolor="anything", on TABLE if setting border="1"? Otherwise you get inset borders. Mild concern that this breaks other content. timloh: Thanks for those details. To continue that thread, you get InsetBorders if you have "unset rules", or a border attribute with some value (non-negative integer? although the code has a fixme noting that the attribute is "a mess"), but no border color attribute. No investigation of how standards-compliant all this is. Is "rules" in any spec? I didn't immediately spot it in HTML, maybe this is some legacy junk we can get rid of. I'm going to remove Bug-Regression because the extra pasted style information is WAI. I'm also knocking the priority down on the basis that we have a workaround at least.
,
Jan 17 2017
,
Jan 18 2017
The interop road here is a very long one. It probably amounts to standardizing how to handle HTML on the clipboard when pasted. That's no bad thing, but it might be better to start in the standards space and come back when there's some basis to interoperate on.
,
Feb 13 2017
,
Mar 29 2017
dominicc: Given comment #17, is there any more action required on this bug at the moment, or is it blocked on spec work? If/when there is more to do, would this be the responsibility of the Style team or of Blink>HTML or of some other component entirely?
,
Mar 29 2017
,
Apr 5 2017
suzyh, the style team needs to spell out why inset borders are so magical. Is that per spec? What do other browsers do? Removing Table since I know you like having one component for something. See comment 15, especially this part: ...you get InsetBorders if you have "unset rules", or a border attribute with some value (non-negative integer? although the code has a fixme noting that the attribute is "a mess"), but no border color attribute. No investigation of how standards-compliant all this is. Is "rules" in any spec? I didn't immediately spot it in HTML, maybe this is some legacy junk we can get rid of.
,
Apr 5 2017
+shans for spec advice
,
Apr 5 2017
Can't reproduce on current stable (m56, win 10) or beta (m57, mac OSX) so even if we had a diagnosis for what was happening here we couldn't fix anything. If you're seeing this issue please make sure your Chrome is updated to the latest stable version. If you still observe the problem then reopen this bug. Thanks!
,
Apr 6 2017
Reopening this; Gmail has probably changed their rewriting in the meantime. Could you read the thread a bit more closely and answer the specific question about whether insets popping into existence is per spec? Where? In particular why are the two ways of setting table borders in Comment 12 different.
,
Apr 12 2017
@tabatkins you know more about the table spec than me (also cc @dgrogan). If you're able to answer Dominic's question please do so then reassign to me and I'll triage further.
,
Apr 12 2017
I guess the pertinent questions are: How would you feel if we stopped processing the rules attribute on tables? Does CSS explain why the TDs computed styles would be border-*-style: inset in this example: http://jsbin.com/hogikekero/edit?html,output
,
Apr 21 2017
Brief answers to dominicc's questions in #26 The rules attribute is "entirely obsolete" in https://html.spec.whatwg.org/#attr-table-rules so we could look into ignoring it. The obvious downside is breaking pages that were written against html4 (https://www.w3.org/TR/html401/struct/tables.html#h-11.3.1) https://drafts.csswg.org/css-tables-3/#mapping includes this pseudo-css that I think explains inset for your example table[border=$border] > :matches(thead,tbody,tfoot) > tr > :matches(th,td) /* if(parseInt($border) > 0) */ { border: 1px inset rgb(128, 128, 128); }
,
Dec 6 2017
,
Feb 4 2018
,
Dec 7
Hello! This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time. - If you are currently working on this bug, please provide an update. - If you are currently affected by this bug, please update with your current symptoms and relevant logs. If there has been no updates provided by EOD Wednesday, 12/12/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary. Thank you!
,
Dec 13
Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information. |
||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||
Comment 1 by tkent@chromium.org
, Oct 28 2016Labels: Needs-Bisect