Closed Bug 1750489 Opened 3 years ago Closed 3 years ago

print.tab_modal.enabled gets ignored in Beta 97

Categories

(Toolkit :: Printing, defect)

Product:
Toolkit
Component:
Printing
Version:
Firefox 97
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: serpher, Unassigned)

References

Details

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

Steps to reproduce:

FF got updated to Beta 97.0b1 from 96 release

Actual results:

File > Print Settings and Print Preview are gone even if print.tab_modal.enabled is set to false

Expected results:

With print.tab_modal.enabled set to false it should show Print Settings and Print Preview (back to old view)

The Bugbug bot thinks this bug should belong to the 'Toolkit::Printing' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Printing
Product: Firefox → Toolkit

See bug 1702501, that preference and its associated code have been intentionally removed from 97.

Yes, as Alice said, this is intentional, and not a bug. If there are things you are missing in the new print UI, please file bugs on that insofar as they do not already exist.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Depends on: 1702501
Resolution: --- → INVALID

The new print dialog is seriously terrible... Is there a new preference, keyboard shortcut or mod of FF that does not use this behavior?
Proprietary software forcing arbitrary UI changes on users is one of the main reasons why many people choose open source. Based on the number of online guides and forum Q&As that called to disable tab_modal by default, I guess that the option had a reason to stay. You are digging your own grave.
I am force-downgrading on all devices I admin for this very reason, despite the security risks, and will abstain from providing volunteer help on the Firefox Help forum.

^(Pinging jscher2000, who seemed to be in support of this decision in another thread without giving a reason, so that he explains it himself or finds somebody who can.)

Flags: needinfo?(jscher2000)

(In reply to Václav Trpišovský from comment #5)

^(Pinging jscher2000, who seemed to be in support of this decision in another thread without giving a reason, so that he explains it himself or finds somebody who can.)

This gave me a good laugh. I was not a fan of the change in Firefox 84 at the time, and I had to tweak the overlay to suit my needs (to enlarge the preview). The good news is that now I can change the printer without printing to it first, and then after changing the printer I can get a proper preview. And I can adjust settings in real time on the panel without opening and closing a separate Page Setup dialog. And best of all I can preview Print Selection if I use that method of calling up the overlay from the right-click context menu.

But I know everyone has their own preferred workflow. There are bugs on file for the following changes that seem likely to come in the near future, although I'm not sure they'll make it into Firefox 98 next month:

  • User preference to bypass preview (and a corresponding Enterprise Policy)
  • Keyboard shortcut to print without preview (bringing parity with Chromium-based browsers)

Would that address your concern or is there something about the display/operation of the overlay itself that you feel needs improvement? Feedback like "terrible" is not actionable.

More generally, I understand that preferences to defer major changes in Firefox can either persist for a long time or disappear quickly. That includes examples like:

  • Tabs moved to top in Firefox 4, preference to revert that removed/ineffective in Firefox 29 (Australis design refresh)
  • Classic search bar drop-down change in Firefox 34, preference to revert that removed/ineffective in Firefox 43
  • Add-on signing introduced in Firefox 43, preference to bypass it removed/ineffective in stable/rapid release of Firefox 48
  • Address bar redesign in Firefox 75, preference to revert that removed/ineffective in Firefox 77
  • Proton design refresh in Firefox 89, preferences to roll back parts of that removed/ineffective in Firefox 91

The trend is toward speeding it up, but Mozilla took an incredibly long time for this particular transition. Even so, there remain some bugs with the implementation. Probably most are on file, but others are just coming to light now because providing an easy way to roll back changes makes it difficult to get full feedback and understand the true impact of changes.

You might wonder "Why not just keep all the old code paths forever?" The reason, as I understand it is, that the development cost is too high. There are a shocking number of tests that need to run every time everything changes, and cleaning up all the unanticipated consequences is a bear, both during pre-release testing, and when some little used feature breaks on release and complaints flood in. I don't envy the job of people who have to makes these decisions, even if I would do some things differently myself.

Flags: needinfo?(jscher2000)

Thank you for the feedback.

My issue with the change, as well as for many other users that I have seen in attempting to Google a workaround, is that it adds extra steps to print to a PDF. On the Mac, this is an option directly in the system print dialog. If the new print dialog included this option, I would be happy to keep it.

Meanwhile, looks like I'll be reverting to version 96.

(In reply to bugzilla from comment #8)

Thank you for the feedback.

My issue with the change, as well as for many other users that I have seen in attempting to Google a workaround, is that it adds extra steps to print to a PDF. On the Mac, this is an option directly in the system print dialog. If the new print dialog included this option, I would be happy to keep it.

Does changing the printer dropdown ("Destination", at the top) to "Save to PDF" not work for you?

Flags: needinfo?(bugzilla)

I'll eat a little crow on this one: after the system print dialog disappeared, I didn't really look around too much and my mind went right to "how do I get the old dialog back"? Now that I've seen that option, the new dialog actually saves a click or two, so yes thank you.

I still believe there's something that should be resolved here - a setting that has no effect. If print.tab_modal.enabled doesn't do anything, it should be removed. ...or does it only appear because I overrode the default value?

Flags: needinfo?(bugzilla)

(In reply to bugzilla from comment #10)

I still believe there's something that should be resolved here - a setting that has no effect. If print.tab_modal.enabled doesn't do anything, it should be removed. ...or does it only appear because I overrode the default value?

The latter. The prefs system is effectively two giant key-value stores - one of the default values, and one of the set-in-the-user-profile values. Code asking for a pref value does the equivalent of checking the second (user-set) one before checking the default values, and about:config simply shows you a combined view using the same method. We don't tend to remove the user-set ones because that would amount to overriding user preferences, even if the profile is then synced to a location where the pref value does have an effect (or copied into a profile running against an older version of Firefox, or...), so you could see why that would also cause people to be upset. I do agree that the presence of the prefs is confusing, but it is generally the lesser of the two evils...

Please return the print.tab_modal.enabled = false option in the new version. I have an old person who is over 80 years old and has a hard time using the new interface. You are young and it is difficult for you to understand that it is difficult for people with disabilities to use the new interface!

(In reply to ilya from comment #12)

Please return the print.tab_modal.enabled = false option in the new version. I have an old person who is over 80 years old and has a hard time using the new interface. You are young and it is difficult for you to understand that it is difficult for people with disabilities to use the new interface!

Can you be specific about the difficulties this person is experiencing and file bugs for those? Is it the fact of the change and needing to re-learn a workflow, or is there something about the old dialog which was easier to use than the new?

Flags: needinfo?(ilya800918)

(In reply to Sam Foster [:sfoster] (he/him) from comment #13)

(In reply to ilya from comment #12)

Please return the print.tab_modal.enabled = false option in the new version. I have an old person who is over 80 years old and has a hard time using the new interface. You are young and it is difficult for you to understand that it is difficult for people with disabilities to use the new interface!

Can you be specific about the difficulties this person is experiencing and file bugs for those? Is it the fact of the change and needing to re-learn a workflow, or is there something about the old dialog which was easier to use than the new?

I'm sorry if I'm not following the rules of this forum. An elderly person has poor eyesight and eye disease, and it is much easier for him to use the standard Windows dialog. The new dialogue looks complicated, confusing to him, there is small font. To call the old dialog, you need to scroll the scroll bars, which are hard to see. or at least make a visible button to call the standard Windows dialog from above, so that it is not difficult to press it.

Flags: needinfo?(ilya800918)

Hi ilya, two notes for now:

(1) If your user clicks "Fewer settings" to reduce the displayed settings on the print setup panel, the "Print using the system dialog" should be visible without scrolling.

(2) If you can make modifications on their installation of Firefox, you can use custom style rules in a userChrome.css file to move the link to the top and also enlarge the entire overlay. That is a somewhat involved discussion for Bugzilla, so let me point you to some threads on Mozilla Support:

I know this not something everyone is able to implement, but unfortunately, add-ons cannot make changes like this.

(2) If you can make modifications on their installation of Firefox, you can use custom style rules in a userChrome.css file to move the link to the top and also enlarge the entire overlay.

Thanks, I have programming experience and will try to do it.

(In reply to ilya from comment #17)

(2) If you can make modifications on their installation of Firefox, you can use custom style rules in a userChrome.css file to move the link to the top and also enlarge the entire overlay.

Thanks, I have programming experience and will try to do it.

When you do, could you please try to make the link “auto-clicked”? Thank you very much. You may need to use custom scripts outside CSS stylesheets though.

I will not update Firefox until either:

  • the link is “auto-clicked” (so that the old print dialog is effectively default again), or
  • a link to printer properties, as seen in the Windows print dialog (that brings up the driver’s set of options) is available in the modal print dialog (at least in Windows distributions of Firefox. Sadly, I haven’t found a Linux program that can invoke similar printer preferences – at least with my installed Epson drivers – but it is definitely possible on Windows, as Adobe Reader, Image Viewer, MS Office and countless other programs with proprietary print dialogs can invoke it just fine.) Many people working in offices don’t realize it but for home inkjet printing, any job is a three-way compromise between speed, price and quality and being able to select hardware-level grayscale (black ink only) and resolution in the properties is essential for anyone who thinks before they print.

Imagine me trying to explain the benefits of open source software to my parents, stating that by selecting a desktop environment, they don’t have companies making arbitrary UI changes for them, and that FOSS software is frequently very easy to modify to fit a specific workflow. Then, they ask “Why do I have to wait for a preview and then click this link whenever I print?” and my point is defeated. Worse case, they don’t learn how to click that link or use the old print dialog, and bother me every time they need a PDF printed.

Just to reiterate - this bug is for an issue that has already been resolved. Its closed and is only getting responses because I happen to be tracking all bugs in this component. As a rule, we'd prefer problems be filed as their own distinct bugs so we can track them, flesh out details and make a plan for fixing them when appropriate. I don't want to shut down constructive feedback and we do want to hear about issues like those raised in comment #15, but please do so in a new bug if possible. Adding a way to select "hardware-level grayscale (black ink only) and resolution in the properties" is a feature we might consider, and certainly something we would want on file. Please file that as its own bug.

(In reply to Sam Foster [:sfoster] (he/him) from comment #19)

"hardware-level grayscale (black ink only)

That should work, that is the "Color mode" option in the sidebar.

resolution in the properties.

That is not exposed, but fwiw we expose print.default_dpi which might allow you to change it (we might override it with the driver value in some cases? I don't recall off-hand).

You need to log in before you can comment on or make changes to this bug.