Maybe introduced when we added 'Back to Website' button (not visible on your screenshot)?

No, I had checked that PR at the time, it was fine - it's broken now:

This could just be a browser issue (updated the issue). Not sure.

I'm not sure to know how to reproduce this one...
by As a customer: Edit that order, what do you mean?
This is what I get:

Hey @jibees ,

Sorry, I guess I should have been more explicit 🙈 I've edited above.
If the enterprise is set accordingly (step 1) and the order cycle is still open then, the customers can edit orders. Do to so, log in as a customer and visit /account#/orders and click Edit for that order:

This will lead the user to the order confirmation screen.

Found it.
This is due to #10103
and that particular line #14:

the <table /> is therefore display: block; instead of its inherit display which is display: table;

FYI this is reproductible on order confirmation page as well. I've just tested on production:

FYI this is reproductible on order confirmation page as well. I've just tested on production:

Yes, I can see it too in order confirmation pages (either editing or after checkout), but only for editable orders. Is that the case, on that pic @RachL ?

Yep!

Hello, is this issue still open? If so, I would love to work on this! :) Thank you!

Sure, thank you @ashwini-seshadri 👍

Thank you @ashwini-seshadri!
I have just checked. The problem is still there, but it's smaller now - at least on my device and browser (Firefox).

Here is a screenshot:

I can still repro the gap on Firefox 130.0.1, but as mentioned in the original message, it doesn't happen on Chrome.

I also found as potential fix the same thing that was brought up in #10261 (comment). The display: block lines added in #10103 for both split-checkout.scss #line-items and cart-page.scss #cart-detail don't seem needed anymore to make the screen wrap on mobile, so maybe it's fine to remove it after all.

If this issue is still up for grab, can I look into preparing a PR for these changes?

Sure go ahead @ndossougbete 👍
I'll assign you. Thanks!

I took some time to look into it today, and I need to correct the statement in my comment above. I think it will be more complicated. The fix added in PR #10103 to address issue #9976 does not seem to be working anymore.

Repro steps:

1. A mobile device or some way to simulate it will be needed. I used the mobile/responsive mode from dev tools. E.g. on Firefox , the Galaxy Note 20 at 412px width.
2. As an admin: In one of the hubs, edit some of the items to make sure a few have some reasonably long name without spaces, so that it is not auto-wrapped. Example: on my simulated phone above, I observed "Mushrooms" to be long enough to cause the issue.
3. As a customer, on a mobile device: Edit an already placed order:
   • Place an order on that hub
   • Visit /account#/orders and click "Edit" for that order -> Notice that the whole page scrolls horizontally

One one hand I don't quite understand why the change to make the table have display: block does not work, but on the other hand I think it's not going to be the right solution. It is mentioned on MDN, but with a caveat:

you'll notice that table's display property has been set to block. While this allows scrolling, the table loses some of its integrity, and table cells try to become as small as possible.

Chrome seems to handle the "cells try to become as small as possible" part better than Firefox, which is why a gap can show up. I found an article mentioning that it might cause some accessiblity issues. And overall, the whole body still scrolls on mobile Chrome & Firefox when a long string without spaces is included in the table. On Firefox is extra bad, compare outcome of executing the snippet here: https://stackoverflow.com/a/48736763. Other difference, in Chrome the "Back to store" button seems to have the wrong size, while in Firefox it matches the size of the buttons below.

I'll have another look when I have some time. Hopefully I missed some simple fix, but maybe it will take a more comprehensive rewrite of the markup to fix this. Maybe CSS-calc'ing the columns get elements with the right sizes?

All that to say that I'll hold off of submitting a PR just removing the display: block properties, it seems irrelevant to do considering the other issues, and even makes things worse in certain cases 😅

And please let me know if I should fork the general table/scrolling issues of these screens to a separate issue.

Hi! I gave up on trying to get the table to work on mobile, and created PR #13010 to fix the bug initially mentioned here.

I think the table will never work properly on mobile and it would be best to try an alternate layout to display this info without needing to scroll. An interpretation of this (that still needs a lot of work to be anything close to shippable) could be something like:
.
It removes some columns and attempts to put the info back in the first cell instead. But that's becoming off-topic, I think the mobile tables should be forked to a separate issue (or reopen #9976 maybe?) if this is to be done.