Page MenuHomePhabricator

Deprecate printable version mode
Open, HighPublic3 Estimated Story Points

Description

Printable version had one main purpose: Support browsers that didn't support media queries yet.
That purpose is no longer relevant, as the last browser (IE 5.5/6.0) that required it, is no longer supported.

A secondary purpose has been identified, which was that people didn't really know how to print a web page (ctrl-p or file->print). To slightly accommodate that use case, while not relying on printable version, this link was recently adapted to trigger the print dialog using Javascript.

A 3rd use has been to check how a page will look in print. Many browser's web inspectors have a mode to do this, and for the general public, most operating systems provide a "print preview" feature.

As the printable version feature is not well maintained, has a few quirks and adds complexity that is avoidable, I suggest we start fully removing support for printable version.

Acceptance criteria

  • Deprecate printableversion (per 1.35)

QA Results - Beta

Sign off

Removal continues in T259141: Remove printableversion mode

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Kghbln added a subscriber: Kghbln.Jun 15 2017, 1:16 PM
Cpiral added a subscriber: Cpiral.Oct 3 2017, 7:14 AM

Right now, it seems TheDJ's script (to convert MediaWiki's server "printable version" into a browser "print page" dialog) is in effect. But then 1) shouldn't we first remove the "printable version" selection from the sidebar's Print/export section of tools? 2) Firefox Reader Mode is now not cooperating. (It's gone, but will show up on PHP pages such as from the "Permanent link" tool in the sidebar.)

What is the status of this ticket? Because two days ago, I actually got a printable version that was a MediaWiki preview of Beilin District Suihua and not my browser's print dialog. It was random. Never saw one before or since.

Now I have to update Wikipedia: Printing to tell users who want a beautiful print preview from MediaWiki servers to 1) select "Permanent link". 2) edit the URL, and change &oldid=## to &print=yes. This is the only way at the moment to get a printable version that is 1) in a browser tab, and 2) showing accurate styling instead of a separate window with inaccurate styling, paper on desktop view, borders view, headers, etc. The "print previews" are just too different to want to replace one with the other.

TheDJ added a comment.Oct 3 2017, 8:33 AM

@Cpiral No, that's a different script, that script is still no more than a user script, and gives you a few more options that a standard print does not give you.

  1. You see "Printable version" if your Javascript did not load, and "Print page" otherwise.
  2. I don't see how Firefox reader mode has anything to do with this. If you have problems with when and how reader mode is available on Firefox, you should direct those at Firefox.

" I actually got a printable version"

Currently it's a link to the printable version, which is then enriched with Javascript. But that depends on nothing interfering with that process. If you have broken user scripts enabled (which many long term users do), this may fail, and you might only have the link to the printable version.

The rest of your comments make little sense to me. Can you try to explain better what you are trying to achieve ?

@TheDJ Thanks, now I can update WP:Print description. But as for the web inspector and an OS print preview, I will need to search out more information on those to update it fully.

No, even my Firefox and Chrome IP (no login) gets just the printer dialog, so it can't be my JavaScript customization. So I have posted at printable version.

Yes, I guess a MediaWiki printable version that operates could be

  • for a one-click, in-browser usage, by all. Firefox and Chrome have started spawning an out-of-browser process with many issues to then interface with and then dismiss.
  • for testing by template developers using noprint and selfref CSS classes. Wikipedia needs to resolve a slew of issues revolving around them, print preview is a major tool.
  • for testing by browser developers. Browsers can have inaccurate print-previews. See how the Firefox (version 56) print preview of the info-box is only a semi-box? (Its lines are missing on the second page, while the info just floats.) This does not occur in the MediaWiki printable version. A printable version that was a gold standard for print-related projects is a thing of simple beauty.
  • for quality testing by end-users, wondering if and when to create a book or archive.
  • for saving paper and technical debt. Why print a test page when you already have an accurate electronic rendition in our printable version page?
  • for relieving some of the development obstacles in of other, offline-related projects by helping contribute a simple, quick, accurate standard view.

The difference in print related projects is the accuracy, and the layout and presentation of the views and controls. Printable version should be the simple-to-use, fast, standard.

TheDJ added a comment.EditedOct 4 2017, 10:20 AM

for a one-click, in-browser usage, by all. Firefox and Chrome have started spawning an out-of-browser process with many issues to then interface with and then dismiss.

Print is print. If you have complaints about how print works, please direct them at your Browser or Operating System vendor. If they are shoddy, consider switching to a better vendor.

for testing by template developers using noprint and selfref CSS classes. Wikipedia needs to resolve a slew of issues revolving around them, print preview is a major tool.

This is probably the primary reason to keep the printable mode. However... I would like to point out that browsers have web inspectors and extensions that can easily provide similar functionality (which is closer to the actual printing behaviour).

for testing by browser developers. Browsers can have inaccurate print-previews. See how the Firefox (version 56) print preview of the info-box is only a semi-box?

eh.. Please file a bug with Firefox... Entire features as a workaround for a browser bug is generally not a good plan. Also, on my Mac, this problem isn't limited to Print preview, it's actually broken in physical Print too !

for quality testing by end-users, wondering if and when to create a book or archive.

I don't quite understand this point. Can you further detail the use case ?

for saving paper and technical debt. Why print a test page when you already have an accurate electronic rendition in our printable version page?

Print previewing is a core feature of most operating systems. And most also have Print-to-PDF built in.

for relieving some of the development obstacles in of other, offline-related projects by helping contribute a simple, quick, accurate standard view.

This is too vague to base any decisions on. But if this means what I think it means, then I would say: There is no such thing as a standard view to begin with. There are tons of exceptions for print, mobile, excerpts, javascript, user groups etc etc. If anything, depending on this, likely will give you a false sense of security.

This feature of printable version is incomplete, as T51722: ResourceLoader does not process media queries for printable view with JS-added CSS proofs, and maintaining an infrastructure that is entirely correct for this is more annoying and hard than we would want it to be, which drives the desire to potentially remove the entire mode. This feature is not gone yet, but the fact that we still have some needs for it, says more about the browser vendors than about us :(

Restricted Application added a project: Performance-Team. · View Herald TranscriptAug 23 2019, 2:11 PM
Krinkle lowered the priority of this task from High to Medium.Aug 23 2019, 2:11 PM
Krinkle moved this task from Inbox to Backlog on the MediaWiki-ResourceLoader board.

The ResourceLoader-code that existed for printable and handheld parmeters looked unused, but I was wrong. It is used in the following way:

  • Sidebar links to "Printable view" (example: index.php?title…&printable=yes)
  • OutputPage arbirtrarily forwards printable parameter to ResourceLoader for use in any of its embedded load.php URLs.
  • There is nothing in ResourceLoader or ResourceLoaderContext that reads or varies its logic by this in any way. Hence my assumption that it is only a Skin-level thing.
  • But behold, when ResourceLoader::makeModuleResponse is concatenating the result of various modules in the main styles-only request, there is a call to OutputPage::transformCssMedia which gets its hands on the internal RL state (after reading and processing of LESS/CSS, but before concatenating), and changes any top-level media block (those defined in Resources.php/skin.json) for "print" to "" so that it applies on screen, and discards any top-level block for "only screen".
    • It does this based on reading out wgRequest directly, thus bypassing ResourceLoaderContext, but relying on wgRequest working inside a load.php request, kind of.

Pratically speaking, this means:

  • mediawiki.toc.styles is loaded in a way where its screen.less is removed and print.css unwrapped in its stead.
  • mediawiki.page.gallery.styles is loaded with its print.css unwrapped.
  • ResourceLoaderSkinModule loads legacy-print unwrapped and omits most of its other stuff.

That's pretty much it. It does potentially have other random impact depending on how extensions have written their styles. I imagine they generally don't have print.css as a separate extension.json entry with "print" as media key though, so I assume the above is the 99% that matters.

What are the blockers for deprecating this in 1.35?
This is causing some real problems in the desktop improvements project - the new Vector breaks in this mode (see T253842) and we currently don't have plans to fix that.

Change 610323 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] Deprecate printableversion=yes

https://gerrit.wikimedia.org/r/610323

I propose adding a banner like so:

and changing the sidebar link as part of the 1.35 release.

As we update Vector we have no interest in fixing the following:

Given this is a performance recommendation, I think now is the time to deprecate this.

Jdlrobson renamed this task from Remove printable version mode to Deprecate and remove printable version mode.Jul 8 2020, 9:33 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a subscriber: ovasileva.

@ovasileva super sorry for the late sprint entry but given my recent analysis of the print mode in T253842, I think it's essential we set the intention that this is not supported and aim for a deprecation in for 1.35 (which is cut on 14 July 2020 at 02:00 UTC.)

@ovasileva super sorry for the late sprint entry but given my recent analysis of the print mode in T253842, I think it's essential we set the intention that this is not supported and aim for a deprecation in for 1.35 (which is cut on 14 July 2020 at 02:00 UTC.)

That sounds good, but let me discuss it with Szymon as well - will get back to you later today

@Jdlrobson - does this mean that the link would still exist but it would just trigger the browser print (i.e. all we're removing is the page like https://en.wikipedia.org/w/index.php?title=1937_Fox_vault_fire&printable=yes)

@Jdlrobson - does this mean that the link would still exist but it would just trigger the browser print (i.e. all we're removing is the page like https://en.wikipedia.org/w/index.php?title=1937_Fox_vault_fire&printable=yes)

The link would exist yes and point to browser print. If there is no JavaScript it will be hidden. The page would also exist but have a banner saying it is no longer supported.

@Jdlrobson - does this mean that the link would still exist but it would just trigger the browser print (i.e. all we're removing is the page like https://en.wikipedia.org/w/index.php?title=1937_Fox_vault_fire&printable=yes)

Note that the "Printable version" link already triggers the browser print in production today.

The printable=yet URL comes in when e.g. we're in Grade C mode, or when one chooses to share the link or open it in a new tab. Those capabilities would no longer be supported.

Jdlrobson raised the priority of this task from Medium to High.Jul 13 2020, 9:20 PM

Branch cut is tomorrow so reflecting reality here.

Blocked on review from @Krinkle. I will backport when that's done.

ovasileva set the point value for this task to 3.Jul 15 2020, 4:26 PM

Change 613171 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@REL1_35] Deprecate printableversion=yes

https://gerrit.wikimedia.org/r/613171

Change 610323 merged by jenkins-bot:
[mediawiki/core@master] Deprecate printableversion=yes

https://gerrit.wikimedia.org/r/610323

Krinkle removed a subscriber: Krinkle.Thu, Jul 16, 5:00 PM

Change 613171 merged by jenkins-bot:
[mediawiki/core@REL1_35] Deprecate printableversion=yes

https://gerrit.wikimedia.org/r/613171

TheDJ updated the task description. (Show Details)Tue, Jul 21, 10:40 AM
Edtadros reassigned this task from Edtadros to Jdlrobson.Sat, Jul 25, 4:42 PM
Edtadros added a subscriber: Edtadros.

Test Result - Beta

Status: ❓ Need More Info
Environment: beta
OS: macOS Catalina
Browser: Chrome
Device: MBP
Emulated Device: NA
Test Artifact(s):

QA steps

❓ AC1: The printable=yes URL comes in when e.g. we're in Grade C mode. The page would also exist but have a banner saying it is no longer supported.
@Jdlrobson, I tried a few Grade C browsers. I could not get the "Printable version" link to appear even with Javascript enabled. Is this as expected? Here is IE 9


✅ AC2: or when one chooses to share the link or open it in a new tab. The page would also exist but have a banner saying it is no longer supported.

✅ AC3: The link would exist yes and point to browser print.

✅ AC4: If there is no JavaScript it will be hidden.

Edtadros updated the task description. (Show Details)Sat, Jul 25, 4:43 PM

@Jdlrobson, I tried a few Grade C browsers. I could not get the "Printable version" link to appear even with Javascript enabled. Is this as expected? Here is IE 9

Yep expected! If there's no link showing that's good

The bits of this that need to be done by 1.35 are now done (and merged into REL1_35), right? In that case, maybe let's drop the tag saying this is a blocker for 1.35 for the rest of the work?

Jdlrobson renamed this task from Deprecate and remove printable version mode to Deprecate printable version mode.Wed, Jul 29, 3:30 PM
Jdlrobson awarded a token.
Jdlrobson updated the task description. (Show Details)

Made a new task for the actual removal since we're doing some QA right now. T259141