Wikipedia:Reference desk/Archives/Computing/2024 February 1

Computing desk
< January 31 << Jan | February | Mar >> Current desk >
Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.


February 1

edit

Table row rendering bug on Chrome and Edge?

edit

I am having a weird problem at work.

We are developing a web application done in HTML, CSS and JavaScript. The back end code for the application is irrelevant as this problem I'm describing here only concerns the front end.

My boss told me that one particular page is displaying the rows in a table in a random order instead of a definite one. I had a look at the page and saw that this problem is only occurring on Google Chrome and Microsoft Edge, not on Mozilla Firefox.

The table in question is a plain HTML <table> with a <tbody> with <tr> rows in it. These rows are displayed in a random order. My boss and I could tell because one of the columns uses a CSS counter rule, and the numbers displayed by this rule are in a random order.

What is weird here is that I had a look at the page DOM with the inspect tool in the developer tools menu, and saw that the rows in the DOM are in the correct order. It's the rendering engine that is putting them in a random order on the actual visible page.

I'm at my wits' end here. Might this be some kind of bug in the browser itself? Has anyone else had a similar experience? JIP | Talk 21:30, 1 February 2024 (UTC)[reply]

Have you run an HTML syntax checker on the page? Also, try to make the simplest version that displays the problem. This may give you a clue about some little thing you're overlooking.  --Lambiam 22:33, 1 February 2024 (UTC)[reply]
I saved the entire web page as "web page, complete" on my local computer at work, including all the images and CSS files. When viewing this web page in the browser, it worked OK on Chrome and Edge too. So I'm not sure how I would go about making a simplest version. JIP | Talk 22:44, 1 February 2024 (UTC)[reply]
I don't code much and not HTML, but the obvious solution would entail progressively removing elements from the original source while preserving the problem. For various reasons, browsers generally modify various stuff beyond simply the links to resources when saving so it's not that surprising if the saved copy is different. If you don't have a test site you can work on and need to work on a local copy, I'd imagine the solution would be to make this yourself i.e. save the unmodified HTML, then save the external resources. If you don't need to test the other resources, you could just keep using the resources from the external site if the security settings allows it. To be honest though, as I said I don't code and definitely not HTML but this sort of stuff occurs to me as the obvious solution. If it doesn't occur to you, is there someone more experienced with debugging HTML who can deal with this? Nil Einne (talk) 10:54, 2 February 2024 (UTC)[reply]
For what it's worth, I just connected to the application on our test server from home through a VPN connection from my Linux PC at home. The bug occurred on Chrome and Edge, but Firefox and Midori showed the page all correctly. JIP | Talk 22:44, 1 February 2024 (UTC)[reply]
If the table is still served without client JavaScript then try to disable JavaScript in Chrome and Edge to see if the problem remains or disappears. PrimeHunter (talk) 11:42, 2 February 2024 (UTC)[reply]
The way to address it will depend on how you have your virtual RAM bypassing cache configured. Brianroswell (talk) 22:34, 3 February 2024 (UTC)[reply]
How do I check that? Note that this is happening at work on both my and my boss's workstations, which use Windows 10, and on my own computer at home, which uses Fedora Linux. But this is only happening on Microsoft Edge and Google Chrome, not on Mozilla Firefox or Midori. JIP | Talk 08:44, 4 February 2024 (UTC)[reply]
Look here.  --Lambiam 13:01, 4 February 2024 (UTC)[reply]