-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove new lines when copy/pasting in Discover #177952
Comments
In Discover you can select and export rows, in JSON format. if you would have a way to select rows and export them as text, row by row, would this cover your use case? |
Moving this from the EUI repo to Kibana, as at a glance I don't think this is an issue with EUI specifically as opposed to Discover |
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
@cee-chen I think this related to When copying the first three rows of an example data grid like this: I get this as the output:
|
I think it's related how EuiDataGrid is handling screen reader content, because I've been testing with a simple div based table, which keeps the rows in lines in the result |
Hi @kertal, I don't want to perform export, in any format, beacause I need to do this copy/pasting very often. The export function is not usable in my case. |
I've made a bit of experimentation with different HTML tags and browsers. Example 1The table use <html>
<head>
<style>
.row {
display: block;
}
.column {
display: inline-block;
}
</style>
</head>
<body>
<h1>Table with <i>inline-block div</i></h1>
<div class="row">
<div class="column">first</div>
<div class="column">second</div>
<div class="column">third</div>
</div>
<div class="row">
<div class="column">first</div>
<div class="column">second</div>
<div class="column">third</div>
</div>
<div class="row">
<div class="column">first</div>
<div class="column">second</div>
<div class="column">third</div>
</div>
</body>
</html> Copying the lines with Chromium (v122) gives:
This is the expected output with a space between each columns. With Firefox (v123):
This is unexpected and firefox insert a new lines between each and every cells. Example 2The next example use the <html>
<head>
</head>
<body>
<h1>Table with <i>table</i></h1>
<table>
<tr>
<td>first</td>
<td>second</td>
<td>third</td>
</tr>
<tr>
<td>first</td>
<td>second</td>
<td>third</td>
</tr>
<tr>
<td>first</td>
<td>second</td>
<td>third</td>
</tr>
</table>
</body>
</html> Result with Chromium (v122):
Kinda expected result but this time, columns are separated with tabs instead of space. And with Firefox (v123):
This is the same result as Chromium. ConclusionUsing the Note that Discover "data table" used to use Strictly speacking, I think using Note that there is also other elements like Let me know what you think about it. Regards. |
thx for the feedback, I don't think we will go back to Table near term. Coming back to my question, it's not about export, or better .. it's about export to clipboard. so you would select the document of interest, and then export them to clipboard .. currently just JSON is supported, that's why I was asking, if we would have an |
Thank you for your point. Indeed, JSON, CSV, etc. All these formats are the wrong ones and are not the point. I'm only looking to copy what's displayed on the screen, nothing more. The problem with your proposal is that :
If we take 1000 lines. The exercise of going through the whole thing, selecting each line of interest by hand, then going back to the top to export to the clipboard is time-consuming. Do you plan to return to Table at a later date? |
Linking elastic/eui#6561 |
@cee-chen Isn't one part of the described problem similar to what's described in this issue: |
Hi, Is there any news / updates or conclusions on this issue? |
Unfortunately I don't believe there's anything we can do to address this on the Kibana side until the upstream issue in EUI is addressed. FWIW I think the best solution to this issue is probably this one since it would allow us to customize the copy behaviour when selecting multiple data grid cells: elastic/eui#6561. |
Newlines aren't related to screenreader text. It's likely an artifact of JSX rendering, and there's not a whole lot we can do there without running output HTML through a minifier (which then treads into dangerously set inner HTML territory). I think Davis's suggestion of prioritizing elastic/eui#6561 instead makes total sense. I'm not sure it's something EUI has time roadmap-wise for though. Would the Discover team be open to contributing the feature to EUI? |
@cee-chen We'll have to discuss how this fits into our roadmap too, but we'll definitely keep this issue open to track on our end, and it might be something we can contribute if we can find some time for it. |
Pinging @elastic/eui-team (EUI) |
Related issue: #179731 |
One minor detail to add...The cell content across columns should be joined with the horizontal tab ( So something like this...
|
- Closes #179731 - Related to #177952 - Related to elastic/eui#6804 ## Summary This PR adds "Copy selection as text" action. <img width="926" alt="Screenshot 2024-07-31 at 18 09 21" src="https://github.com/user-attachments/assets/a4fc7456-7cd9-4493-a4dd-45151f845566"> ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers) --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Davis McPhee <[email protected]>
@kertal Now that we have the "Copy as text" functionality that copies selected rows in the expected TSV format, do you think we should close this issue or keep it open for elastic/eui#6561? |
Hello, Thanks for the update on this issue, I appreciate that you keep working on it. However, as mentioned previously in the thread above, the proposed solution is really inconvenient. Would you really click on these "small select buttons" 1000 times, click the
That is only 4 actions vs 1000 + 2 actions. Not mentioning this could be done tens or thousands of time each day as an analyst. Again, this is something that any tabular software supports natively (including the browser itself) and it used to work in Kibana as well. So to me, it really sounds like a regression bug. Is there any reason why this bug (feature?) isn't solved yet? Regards. |
You certainly don't need to click those select buttons 1000 times, we support selecting all So it's still not 100% what you're are asking for, but we improved what's possible from Kibana side. What you are asking for is blocked by a bug in Chromium, and the issue in EUI was closed since there seems to be no intention to resolve it: So I think we did what we could from Kibana side, I upvoted and subscribed to the Chromium bug, but I don't think we will iterate on this from Kibana side, so I'd say @davismcphee it's a not planned ... or an iceboxed feature, so it is still tracked when our requirements could provide a solution for this |
Thanks @kertal for the quick response.
The example shown in the previous post was a bit too simplistic, so I will rephrase it. Suppose there is 300 lines in discover and you only want to select the 100 lines in the middle of it. Or even worse, fifty lines here, two there, another thirty here, etc. How one would do to extract those without selecting them one by one? The "select all" feature doesn't seem to be of any help here. Also, @cee-chen, could you explain why this issue has been moved from the EUI repository into Discover? This is clearly an issue in the EUI part, while Discover is only a consequence of it. As demonstrated by @davismcphee, the bug is reproducible in any Right now we are stuck with the "legacy mode" and cannot use any new features introduced since EUI. Column resizing or cell wrapping comes to my mind. In addition, we are a bit worry that this mode might be dropped in the future and cannot use Kibana anymore.
I think we are mixing two issues here. One is the "screen reader text" and the other one (this issue) are the new lines. From my understanding, what is blocked by a "bug in Chromium" is a possible workaround using a CSS trick with Back the new line bug, I really think this is a CSS/style issue. It is possible to have it working in both Firefox and Chromium as shown here. So this is an implementation bug. How does the other Webapp does that Kibana don't to make it possible to copy a table in a proper way? Another example here on Github:
Selecting them CTRL+C/CTRL+V produces this result in Notepad:
So, I really think this is not related to any Browsers bugs. Looking forward to your returns. |
@juste-bob I think your usecase, aiming to select 100 lines in the middle of 300 should be covered by implementing a shift-select solution? #192366 |
It absolutely is a browser rendering issue. Your example works because the table content is simple strings/inline display content. Try this example instead with block display content:
They paste with newlines and not on the same lines. Inspect the DOM; there's nothing going on here except vanilla What's happening is that browsers determine newline behavior in clipboard based on the display property of elements. Inline displays do not cause newlines, block type displays do. Furthermore,
So essentially: any EUI table or datagrid with any kind of complex rendered component (for example, EuiBadge or EuiHealth) will generate newlines (you can test this for yourself in our table docs examples which do use |
Hello,
I coming back on this subject since the last topic was automatically closed. There is still issues when copy/pasting the Discover's output.
In the following example, there is 3 columns (@timestamp, host, report_desc). When copying the first 3 lines (see screenshot attached) I have the following output (ELK is 8.12.2):
While the expected output is:
We are currently working around this issue by turning on the legacy's doc_table: doc_table:legacy.
Could it be possible to patch it ?
Thanks in advance.
The text was updated successfully, but these errors were encountered: