Table TD right border not rendered - FF (92.0.1 (64-bit))
Categories
(Core :: Layout: Tables, defect)
Tracking
()
People
(Reporter: janmika7, Unassigned)
Details
Attachments
(1 file)
|
47.41 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0
Steps to reproduce:
I displayed table with css including border for each <td> element see attached picture.
Actual results:
Table in some case do not render right border for the right most <td> see attached picture.
Other browsers display the border correctly.
Expected results:
The right border should have been displayed.
The same border was not displayed even if added directly to particular <td> element
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Tables' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•4 years ago
|
||
The severity field is not set for this bug.
:alaskanemily, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 3•4 years ago
|
||
Could you please attach a complete example file (HTML+CSS) where you're experiencing this issue? Thanks.
If you zoom the page to display everything larger, do the "missing" borders become visible?
If I zoom the page to display everything larger "missing" border does not appear.
It is very difficult to isolate complete example (HTML + CSS) from my (react) application. I tried but I could not emulate the same behavior. Also it happens only for some specific table and more over in rare cases (for unknown reason) is border visible even for this table.
May be it is related to the fact that table is generated dynamically from ajax data (json), while when I isolate it is static table.
Comment 5•4 years ago
|
||
I think we've had some long-standing bugs with table-cell borders sometimes not being drawn correctly, but without a concrete example it's difficult to know if this is an existing or new issue. Marking as S4 for now, as it seems probably quite rare (and more of a cosmetic than functional issue). If we could get enough detail to reproduce the problem, there'd be a better chance of making progress here.
Updated•3 years ago
|
Description
•