Closed Bug 1854165 Opened 1 year ago Closed 9 months ago

Dynamically-generated shipping label (for sellers) is blank at stallionexpress.ca, eBay.ca, Etsy.com, etc., if extensions.InstallTrigger.enabled is true

Categories

(Web Compatibility :: Site Reports, defect)

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 117
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mozilla.r27kt, Unassigned)

References

Details

Attachments

(2 files)

Screenshot of print preview window
95.73 KB, image/png
Details
app-caaa52d0.js
2.28 MB, application/x-javascript
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

Try to print a shipping label from stallionexpress.ca, eBay.ca, Etsy.com, etc.

Actual results:

  1. Print preview box is blank.
  2. Switching destination or "printers" remains blank.
  3. Actually printing this page prints out a blank shipping label.

NOTE: When you DOWNLOAD a local copy of the shipping label on websites that support this, such as Stallion Express, and you try printing the label, it DOES work as expected.

Not all websites allow you to download the label. Many just "stream" the label to you/download a temp version inaccessible by you.

Expected results:

  1. Print preview box should show a preview of the shipping label.
  2. Pressing Print should print out the shipping label, not a blank page.

The Bugbug bot thinks this bug should belong to the 'Core::Print Preview' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Print Preview
Product: Firefox → Core

Thanks for the bug report.

(In reply to Joshua from comment #0)

Try to print a shipping label from stallionexpress.ca, eBay.ca, Etsy.com, etc.

To clarify: is this with a "return" shipping label, or a shipping label for a seller to use, or something else? (It might not matter; just want to be sure we end up looking at the right thing, if/when we're able to get to the right place in the sites to test this.)

Also, do you know if this used to work and broke at some point recently? (If so, it might be possible to use https://mozilla.github.io/mozregression/ to identify when it broke, if you're willing to install that tool to bisect between Firefox versions and isolate which Nightly build was the first one to be broken.)

I'm curious to test and investigate myself; but, without being a seller or having a product to return, I imagine there might be some hoops to jump through before I or someone else on the rendering team can get to the right sort of page where we can poke at this... So, any tips on how to make that easier are appreciated!

(In reply to Daniel Holbert [:dholbert] from comment #2)

Thanks for the bug report.

(In reply to Joshua from comment #0)

Try to print a shipping label from stallionexpress.ca, eBay.ca, Etsy.com, etc.

To clarify: is this with a "return" shipping label, or a shipping label for a seller to use, or something else? (It might not matter; just want to be sure we end up looking at the right thing, if/when we're able to get to the right place in the sites to test this.)

This was with a shipping label for a seller to use. I am the seller, inputting the data and receiving a shipping label to print off.

Also, do you know if this used to work and broke at some point recently? (If so, it might be possible to use https://mozilla.github.io/mozregression/ to identify when it broke, if you're willing to install that tool to bisect between Firefox versions and isolate which Nightly build was the first one to be broken.)

It worked in the past, then broke randomly a few months ago. I can confirm that it wasn't working in version 11.2.0.2, 113.0 BETA, 113.0.1, 114.0, 117.0.1

I don't know the exact version that it stopped working, as I first blamed the website and didn't look at the Firefox version. I also know that it never started working, but I did stop looking at version numbers, which is why my "confirmed" versions jumped from 114.0 to 117.0.1 above.

I have come with some findings, though.

I used the mozregression tool to test on versions I KNOW it wasn't working, and it WORKED. This lead me to believe that maybe it was something to do with my extensions, so I started disabling them one by one, with no luck.

I then "clear saved print settings" under menu > help > more troubleshooting information, with no luck.

I deleted user preferences file, no luck.

I created a new profile, no luck.

I launched Firefox in Safe Mode, no luck.

I "refreshed" Firefox, no luck.

I uninstalled Firefox, no luck.

I manually deleted all Firefox data, Windows registry values, etc, with no luck.

I also made sure to NOT sign into my Firefox account during any of this, to rule out any potential issue being synced back each time.

What DID work, was installing Firefox Nightly.

Firefox Release, Beta, and Developer versions all have this issue for me, but Firefox Nightly pulls up the preview and prints the file with no issue.

Thanks - that's really handy to know.

It sounds like this is related to some about:config preference that's enabled-by-default only in Nightly (and perhaps has been for a little while). That would explain why you're seeing it working in current Firefox Nightly and also in older builds launched from mozregression (which uses archived Nightly builds).

In the interests of getting to a state where a Mozilla developer can take a look at an affected page -- I'm wondering the issue might reproduce in a saved copy (in which case you might be able to share that and we could investigate without needing to literally be a seller).

Could you try the following:

  1. Load up a page with a shipping label that's ready to print in one of the affected sites, like right before you would normally get to a broken print preview dialog.
  2. Do File|Save As (or Hamburger-Menu | Save Page As)
  3. Make sure the save dialog shows "Web Page, Complete" as the save-type.
  4. Try loading the saved file and see if it reproduces the issue.
  5. If so: make a zip file that has the saved html file and its accompanying resources folder (e.g. foo.html and foo_files/) and send that to dholbert at mozilla dot com, and I can take a look?

I attempted to save the page, but I am assuming the way the website serves the labels, the functionality is completely lost on the saved version.

I am not a web developer, but the website essentially has no static elements, and pressing "print" on the label causes a modal box to pop up with a second "print" button, which then fetches the label directly from an AWS server. It's not like an amazon return label where it's presented statically on the page for you to print.

I think that's also what's causing the issue of blank labels. Like I said originally, If I try to print downloaded shipping labels/PDF's, or even just static web pages, emails, etc., it works fine on any Firefox version currently out there. It's when I attempt to print a shipping label served in this way that it happens.

If there's another way to save this page and retain functionality, I would be happy to do so!

(In reply to Joshua from comment #5)

I attempted to save the page, but I am assuming the way the website serves the labels, the functionality is completely lost on the saved version.

Thanks for trying that. That's too bad that saving doesn't preserve enough functionality to trigger the bug.

If there's another way to save this page and retain functionality, I would be happy to do so!

Thanks! I don't know of a better way to save the site that'd preserve things here, unfortunately.

A few ideas for other approaches here:
(1) If you haven't already, you might try one of the other that you mentioned in comment 0 (you mentioned stallionexpress.ca, eBay.ca, Etsy.com ). I'm not sure if you tried save-as on all of those, but if one of them is affected and does retain enough of the functionality when you do "save as" just before you hit the final print button, then that'd be awesome.

(2) You might check your Web Console (open with "Ctrl+Shift+K", and then click "XHR" and "Requests" to include everything), and see if anything interesting appears there at the moment that you click the final print operation -- e.g. maybe some image or JavaScript file failing to load, or an exception being thrown. It'd be particularly useful to see if there are any errors/warnings that appears in Firefox release (where the bug does reproduce) but does not appear in Firefox Nightly (where the bug doesn't reproduce) -- then that could be a clue about what the relevant feature is, that's producing different behavior between those versions.

(There might be zillions of lines of output, so you might e.g. use the trash icon at the top-left of devtools to throw away the past logging before you hit the final print button, to help focus in on what happens when you hit that. Though also, it's possible the relevant failure is something that happens earlier. Hard to know, but maybe there'll be some obvious clues.)

(3) If those^ don't turn up anything, we may be at a loss for how to debug remotely over Bugzilla, and the only way forward might be for a Mozilla engineer to try to get access to a seller account for test purposes (whether from you or from one of the sites). If it comes to that & if you're willing, one "lightweight" way to do that (without requiring any actual password-sharing) would be for e.g. the two of us to set up a Zoom or Google Meet session where you could screen-share and poke at the site, and if I notice any clues, I can suggest actions that you might take to poke further.

Let's try (1) or (2) -- maybe (2) first -- before worrying about resorting to (3), anyway. :)

(toggling needinfo to be sure you see comment 6 -- I'm particularly curious in (2), i.e. if the web console shows any clues in terms of different-warnings/errors-between-release-vs.-Nightly. No rush though. Thanks!)

Flags: needinfo?(mozilla.r27kt)

Sorry about that, I missed the reply.

When I use the web console on Firefox Stable, it does throw three warnings that aren't shown in the Nightly console.

Cookie “_fbp” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

InstallTrigger is deprecated and will be removed in the future.

Will-change memory consumption is too high. Budget limit is the document surface area multiplied by 3 (31700 px). Occurrences of will-change over the budget will be ignored.

and then both Stable and Nightly show this warning

Warning: Invalid absolute docBaseUrl: "blob:https://ship.stallionexpress.ca/53ms22r6-qvyf-4b24-v5o9-qgh8p32g346".

Flags: needinfo?(mozilla.r27kt)

Thanks! The InstallTrigger warning that you mentioned might be relevant, since it does correspond to a configuration flag that differs between release vs. Nightly, and it is related to occasional mysterious site breakage. So it might be the sort of thing that we're looking for here per comment 4. Following that possible-clue: in your Firefox stable build (the one that reproduces the bug), could you visit about:config and set extensions.InstallTrigger.enabled to false, and see if that makes any difference here?

If that doesn't help, then I think we're left with options (1) or (3) from comment 6 as possible-ways-forward.

(For (3): if you're up for doing a video call where you could demonstrate the issue and I could ask you to check various things in DevToools to come up with clues, and/or if you'd be comfortable privately sharing credentials for one of the reproducing sites so that I could look directly, we can coordinate over email; feel free to reach me at dholbert@mozilla.com . No worries if you're not comfortable with those options, though.)

(note: you don't need to restart the browser after toggling extensions.InstallTrigger.enabled, but you probably do need to reload any relevant pages for them to pick up the result of that pref-flip.)

Changing extensions.InstallTrigger.enabled to false worked!

Hooray, glad to hear it!

Not so glad to hear that that's the underlying issue, though. That means this is a website bug, essentially; the sites are doing different things depending on whether or not they think you're using Firefox, and they're testing for the presence of this ancient Firefox-specific InstallTrigger API as a way of checking which browser you're using. And unfortunately, their Firefox-specific codepath triggers this breakage; but things go just fine if we take their other codepath, the codepath that other browsers get.

Could you list the sites where you've confirmed that (a) the problem exists and (b) this pref-flip fixes the problem? In some cases we might be able to reach out and get the sites to fix their bug (just removing the broken Firefox-specific codepath), but I want to be sure we're reaching out to the right sites. (You mentioned "stallionexpress.ca, eBay.ca, Etsy.com, etc." in comment 0 -- it'd be great if you could confirm the problem and the fix for all three of those sites, and if you could let us know if there are any other sites hiding in your "etc." there. :))

Component: Print Preview → Desktop
Product: Core → Web Compatibility
Summary: Shipping Label Print Preview & Actual Print is blank → Dynamically-generated shipping label (for sellers) is blank at stallionexpress.ca, eBay.ca, Etsy.com, etc., if extensions.InstallTrigger.enabled is true

(denschub, maybe we could add an intervention here, related to the other interventions in bug 1774005? Note that in this case, the sites reportedly only work if InstallTrigger is hidden (the state we'd eventually like it to be in everywhere, per bug 1776423); I imagine this is the opposite of many of our other InstallTrigger-related interventions, but hopefully we can force either behavior?)

Flags: needinfo?(dschubert)

I should be doing the webcompat work for v120, so I'll take the needinfo. Thanks for the heads-up!

Flags: needinfo?(dschubert) → needinfo?(twisniewski)

(In reply to Daniel Holbert [:dholbert] from comment #12)

Could you list the sites where you've confirmed that (a) the problem exists and (b) this pref-flip fixes the problem? In some cases we might be able to reach out and get the sites to fix their bug (just removing the broken Firefox-specific codepath), but I want to be sure we're reaching out to the right sites. (You mentioned "stallionexpress.ca, eBay.ca, Etsy.com, etc." in comment 0 -- it'd be great if you could confirm the problem and the fix for all three of those sites, and if you could let us know if there are any other sites hiding in your "etc." there. :))

Toggling needinfo=reporter for this ^ request (thanks!)

Also, more importantly: could you share the link to the JavaScript source file that's triggering this InstallTrigger warning? You should be able to find that in the developer console, to the right of the InstallTrigger is deprecated and will be removed in the future warning message (in a Firefox build with extensions.InstallTrigger.enabled set to true). Right-click the blue link at the right of that message, and choose "Copy link location", and share that URL here.

(Presumably that'll be the problematic JavaScript library in question which is the common thread amongst all the affected sites here. We can probably craft an intervention that suppresses this API specifically for sites that use that JavaScript library, once we know what it is, to fix this for all Firefox users.)

Thanks!

Flags: needinfo?(mozilla.r27kt)

Sorry for the late reply, it took a while to test all the websites. Currently, with Firefox 118.0.1 with extensions.InstallTrigger.enabled set to true, only StallionExpress.ca is displaying the error and having the issue.

Also, more importantly: could you share the link to the JavaScript source file that's triggering this InstallTrigger warning?

https://ship.stallionexpress.ca/build/assets/app-7aba22b9.js

Flags: needinfo?(mozilla.r27kt)

(In reply to Joshua from comment #16)

Sorry for the late reply, it took a while to test all the websites.

No worries; I appreciate you testing them!

Currently, with Firefox 118.0.1 with extensions.InstallTrigger.enabled set to true, only StallionExpress.ca is displaying the error and having the issue.

OK, cool. So it sounds like eBay and etsy don't directly have this issue after all, correct? (Maybe you were hitting this issue when generating shipping labels for orders that were placed on those sites?)

(Just double-checking to be sure that any intervention that we might write is properly-scoped.)

https://ship.stallionexpress.ca/build/assets/app-7aba22b9.js

That URL doesn't load for me, but when I visit https://ship.stallionexpress.ca , I do end up loading a script with a nearly-identical name (just a different hash suffix): https://ship.stallionexpress.ca/build/assets/app-caaa52d0.js
So I'm guessing the hash suffix is specific to a particular deployment, and they've deployed a new version in the past day or so,.

I'll attach their app-caaa52d0.js for archival/reference here. It does indeed use InstallTrigger to activate some Firefox-specific codepaths, but the code is minified, so it's a bit hard to see what's going on.

Attached file app-caaa52d0.js —

Here's the current contents of https://ship.stallionexpress.ca/build/assets/app-caaa52d0.js , which I think/assume is still involved with triggering this issue.

(Warning, it has no newlines and might take a while to load in a text editor)

(In reply to Daniel Holbert [:dholbert] from comment #17)

OK, cool. So it sounds like eBay and etsy don't directly have this issue after all, correct? (Maybe you were hitting this issue when generating shipping labels for orders that were placed on those sites?)

As of Version 118.0.1 and 2023-10-09, only StallionExpress.ca currently has the issue, correct!

Great. Thanks again for all your help here. I think twisniewski is going to add an "intervention" that's specific to that site, then, to do the equivalent of toggling that about:config preference just for that site. (We might ask for your help one more time once that's been deployed, to confirm whether it's behaving as-expected.)

Just FYI, the proposed fix for this should be in the latest nightly builds by now, in case anyone would like to confirm whether it works as expected before it hits the mainline Firefox release.

Flags: needinfo?(twisniewski)

A shipping label is needed to test this issue. Joshua, is the issue still reproducible for you, on both Nightly and Release version of Firefox?

Flags: needinfo?(mozilla.r27kt)

(In reply to Raul Bucata from comment #22)

A shipping label is needed to test this issue. Joshua, is the issue still reproducible for you, on both Nightly and Release version of Firefox?

I can confirm that this issue is fixed in the latest Firefox release v123.0

Flags: needinfo?(mozilla.r27kt)

Glad to hear that, let's close this as FIXED. Please keep us posted if the issue re-occurs.

Status: UNCONFIRMED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: