eBay.com Order Information "Printer friendly page" looks broken (content too small or gets clipped) in Firefox, because it forces a 1000px-wide root element **only for Firefox** via UA sniffing
Categories
(Web Compatibility :: Site Reports, defect, P1)
Tracking
(Webcompat Priority:P1, Webcompat Score:8)
People
(Reporter: dholbert, Unassigned)
References
()
Details
(Keywords: webcompat:contact-complete, webcompat:site-report, Whiteboard: [webcompat:sightline])
User Story
platform:windows,mac,linux impact:workflow-broken affects:all configuration:general branch:release user-impact-score:800
Attachments
(3 files)
screenshot of bug (fit-to-page-width forcing severe downscaling, with stock Firefox)
STR:
- View an order that you've placed on ebay.com (URL should look like
https://order.ebay.com/ord/show?orderId=[...]#/with some numeric orderId) - Click "Printer-friendly page" at the top right.
--> (This pops up a modal overlay (as part of the same page) with displayed title "Printer friendly page" and a simpler version of the order info below that.) - Click the print icon at the top-right of the "Printer friendly page" overlay.
ACTUAL RESULTS (in "stock" Firefox):
- eBay opens a popup window with a print-preview version of the page
- In that print-preview version of the page, everything looks too small to read, and there's no real way to make the content larger.
- eBay seems to be forcing a layout where the order details table isn't allowed to shrink to fit the available area, I think; so a long "Item name" ends up being forced to lay out on a single line, which makes the document as-a-whole wider than the available space on the page, which results in the document being scaled down to fit (via "Fit to page width").
- If a user tries to fix this by increasing the scale in the print dialog, that just causes content to run off the edge and be clipped (since ebay's design here isn't responsive to the available width).
BETTER RESULTS (in Chrome, and in Firefox spoofing a Chrome UA string):
- eBay doesn't open a popup window; they just directly open a print dialog in the existing browser window.
- In that print dialog, the text is big enough to be readable.
- The order details table (and the long product-name) is allowed to fit the available space and linewrap as-needed.
- If I manually increase the scale in the print dialog, it behaves as I expect; content gets bigger, lines wrap more aggressively, and nothing is clipped.
eBay seems to be doing UA-string-spoofing and is specifically giving Firefox users a bad experience here, presumably by accident. We should do some outreach to them to see if they can fix this, to give Firefox users the same experience that Firefox-spoofing-a-Chrome-UA-string gets.
|
Reporter | |
Comment 1•1 year ago
|
||
Here's the much-better print layout that we get if I use "User Agent Switcher" add-on to make Firefox report a Chrome user-agent string.
|
|
Reporter | |
Updated•1 year ago
|
|
|
Reporter | |
Comment 2•1 year ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #0)
BETTER RESULTS (in Chrome, and in Firefox spoofing a Chrome UA string):
[...]
If I manually increase the scale in the print dialog, it behaves as I expect; content gets bigger, lines wrap more aggressively, and nothing is clipped.
Here's a screenshot to illustrate this^.
(In contrast, with the default Firefox user agent string, the "scale" selector just causes content to run off the right side of the page and be clipped)
|
|
Reporter | |
Comment 3•1 year ago
•
|
||
The issue here seems to come from this stylesheet:
https://ir.ebaystatic.com/rs/v/suayygjleuzghbwiach453coxau.css
...which has this CSS rule that applies to the <html id="print-html"> root node here (whitespace added for readability):
@media print {
[...]
#print-html {
width:1000px
}
(There's also this a bit further down...
@media print and (orientation:landscape) {
[...]
#print-html {
width:1200px
}
...but I don't think that 1200px one is ever activated here, since this page forces itself to have @page { size: A4 portrait } in an inline stylesheet.)
That explicit 1000px width on the root html node causes the document to be 1000 CSS Pixels wide, regardless of how much space is actually available on the page. If we don't have that many CSS pixels worth of printable area on the page, the browser has to either shrink that 1000px document area to fit the actual space on the page (resulting in extremely small text), or clip it to fit (resulting in missing data).
That hardcoded width is the proximal thing to be fixed here.
But really, ideally we can just have eBay give us their other printing codepath, where they don't use a popup document and don't have id="print-html" on the root node of the document that gets printed (which means we avoid tripping the troublesome CSS rules that I quoted above.)
|
|
Reporter | |
Comment 4•1 year ago
|
||
[whoops, adjusting bug title; it reflected my original assumption that the downscaling here was coming from the @page { size: A4 portrait } styles, but it turns out they have that in the "good" layout as well, and the troublesome bit is in fact the hardcoded width per comment 3]
|
|
Reporter | |
Updated•1 year ago
|
|
|
Reporter | |
Comment 5•1 year ago
|
||
I reached out to our eBay contacts about this, to see if they can help get this addressed.
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
|
|
Reporter | |
Comment 6•1 year ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #5)
I reached out to our eBay contacts about this, to see if they can help get this addressed.
I just retested, and confirmed that this is still reproducible (using Firefox Nightly 128). The issue still goes away if I override my UA string so that Firefox pretends to be Chrome.
I followed up with the eBay contact list to hopefully get this onto their radar.
|
||
Comment 7•1 year ago
|
||
Dan, do you know if this still reproduces and whether your suggested intervention would still be helpful?
|
|
Reporter | |
Comment 8•1 year ago
|
||
It still reproduces for me, yup. I confirmed that I can still work around it by spoofing a Chrome UA string (e.g. with Chrome Mask) for order.ebay.com.
FWIW I did get a response to my ebay-contact-list-poke in comment 6, but it may have dropped off the radar -- so I emailed the eBay list again. I got an autoresponse from the person who'd replied last time, saying they're out for the rest of the week, so we might not hear back right away.
|
||
Updated•1 year ago
|
|
||
Updated•1 year ago
|
|
|
||
Comment 9•1 year ago
|
||
The severity field for this bug is set to S3. However, this bug has a P1 WebCompat priority.
:ksenia, could you consider increasing the severity of this web compatibility bug?
For more information, please visit BugBot documentation.
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
|
|
Reporter | |
Comment 10•1 year ago
|
||
Good news, it seems eBay has fixed this and removed the UA-sniffing-based differential behavior here.
At least: I'm seeing the comment 0 "BETTER RESULTS", with a rendering that looks like comment 2, in Firefox 135.0 (64-bit) and mozregression-launched Firefox Nightly from the day this bug was filed (2024-03-27).
--> Closing as FIXED.
|
|
Reporter | |
Updated•1 year ago
|
Description
•