Bug #10187
closedInsertion of ZERO_WIDTH_SPACE into IPv6 addresses make it impossible to use browser find functionality
0%
Description
Yes, seriously. For some bizarre reason a ZERO_WIDTH_SPACE is inserted after every colon in an IPv6 address on both the Alerts and Blocks pages. Try to broswer-find any address and you're with only the first hextet. Whatever table generator is being used needs to be whacked upside the head.
Updated by Bill Meeks almost 5 years ago
This was done by design to preserve the page display asthetics. When you copy-paste using the pfSense GUI or do other operations within the pfSense GUI, the zero-width spaces are automatically removed.
If you are viewing the raw HTML in the browser and searching that way, then yeah, you will need to compensate for the zero-width spaces.
This is not a bug. It is a feature that has been in the package for years. Without the zero-length spaces the HTML renderer sees no place to "break" an IPV6 address for display in the table cell and thus runs it way over or just cuts it off where you can't see the entire string.
Updated by Izaac Falken almost 5 years ago
No, I am not viewing raw HTML. I'm hitting Ctrl-F in Firefox. Find-in-page breaks on breaks.
While I appreciate the kiddie's-first-intro to page layout, I will point out that the pfSense rules pages neither suffer this problem nor use ZERO_WIDTH_SPACE. Perhaps using an engine which doesn't slam style="word-wrap:break-word; white-space:normal
into every <td> tag JUST MIGHT also achieve this objective without breaking the most basic and useful kinds of in-browser user experience.
(And dropping 96 bytes for every row JUST MIGHT help page load times, too.)
Updated by Bill Meeks almost 5 years ago
Izaac Falken wrote:
No, I am not viewing raw HTML. I'm hitting Ctrl-F in Firefox. Find-in-page breaks on breaks.
While I appreciate the kiddie's-first-intro to page layout, I will point out that the pfSense rules pages neither suffer this problem nor use ZERO_WIDTH_SPACE. Perhaps using an engine which doesn't slam
style="word-wrap:break-word; white-space:normal
into every <td> tag JUST MIGHT also achieve this objective without breaking the most basic and useful kinds of in-browser user experience.(And dropping 96 bytes for every row JUST MIGHT help page load times, too.)
The difference in the rules page versus the Suricata and Snort ALERTS tab is the sheer amount of displayed information. The columns are too narrow to display a full unbroken IPv6 address without the need for a lot of horizontal scrolling.
You are welcome to submit a modification to the PHP code that works better. Here is the link: https://github.com/pfsense/FreeBSD-ports/tree/devel/security/pfSense-pkg-suricata.
Updated by Izaac Falken almost 5 years ago
Bill Meeks wrote:
You are welcome to submit a modification to the PHP code that works better.
'k.
Updated by Jim Pingle almost 5 years ago
- Status changed from Not a Bug to Needs Patch
Updated by Bill Meeks almost 5 years ago
Izaac Falken wrote:
Bill Meeks wrote:
You are welcome to submit a modification to the PHP code that works better.
'k.
Don't forget to test any modifications with the most popular browsers. Those would be Chrome, Firefox, Safari and Microsoft Edge at a minimum. When I worked on that code long ago there were many differences between the browser rendering engines with regards to how they handled breaking long text in table cells. That's why all those particular styles are embedded in the <td> tags.
Updated by Izaac Falken over 3 years ago
If this is waiting for me to submit a patch: it ain't coming.