Remove the "Print Frames" section of the print dialog (frameset specific UI)
Categories
(Toolkit :: Printing, defect, P1)
Tracking
()
People
(Reporter: jwatt, Assigned: jwatt)
References
Details
Attachments
(8 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
Framesets are nowadays very rare (so much so, they've been moved to the Non-conforming features section of the HTML5 spec that says "Elements in the following list are entirely obsolete, and must not be used by authors").
Despite that, we continue to have a section of our Print dialog dedicated to handling frameset frames (unlike Chrome, Safari, IE, Edge which haven't had frameset specific UI for many years). Specifically, on a frameset page the following section is enabled (it's even visible, if greyed out, on mac):
Print Frames
* As Laid Out on the Screen
* The Selected Frame
* Each Frame on Separate Page
In addition to the points given above, for almost all Firefox users this section isn't going to make sense when they encounter it since it requires some understanding of what framesets and "frames" are.
I propose that we remove this UI and hardcode the "As Laid Out on the Screen" behavior, in line with other browsers.
My immediate motivation for doing this is that it would allow us to simplify some of the rats nest that is the code in layout/printing. This code badly needs refactoring and simplification to make it possible to reason about. I'm particularly eager to do that to ease the path and lower the risk of printing related Fission work.
Mike, what would be the best way to make quick progress on this? I would like to avoid having this held up for months waiting for the attention of people that need to signoff on such a change given the relevance for Fission. I'm happy to do the actual work here (with a little guidance).
Assignee | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
As an added bonus I think this would mean we could remove all of the dialog modification code in widget/windows/nsPrintDialogUtil.cpp
Which I think would make it much easier to move to PrintDlgExW (in the same file) instead of PrintDlgW, which is essentially deprecated.
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms646940(v=vs.85)
Comment 2•5 years ago
|
||
This makes sense to me given the understanding required to know what a frame is and the obsolescence of frames.
Comment 3•5 years ago
|
||
I propose that we remove this UI and hardcode the "As Laid Out on the Screen" behavior, in line with other browsers.
That sounds like the right way forward indeed.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 5•5 years ago
|
||
The 85 pixel change in y-axis offset is the distance between the "Print
Background Images" checkbox and (removed) "Each Frame on Separate Pages" radio
button.
Assignee | ||
Comment 6•5 years ago
|
||
Note that this makes Firefox use the standard system Print dialog as opposed
to just removing our "Frames" section from our custom dialog.
Assignee | ||
Comment 7•5 years ago
|
||
Depends on D33389
Assignee | ||
Comment 8•5 years ago
|
||
Assignee | ||
Comment 9•5 years ago
|
||
Depends on D33623
Assignee | ||
Comment 10•5 years ago
|
||
kFrameEnableNone is synonymous with having a non-frameset document. This makes
what is going on here explicit. It also gets rid of the kRangeSelection based
override and makes that explicit too.
Assignee | ||
Comment 11•5 years ago
|
||
Assignee | ||
Comment 12•5 years ago
|
||
Comment 13•5 years ago
|
||
Pushed by jwatt@jwatt.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/b58a59871bca Remove macOS print dialog UI for selecting frameset behavior. r=mstange https://hg.mozilla.org/integration/mozilla-inbound/rev/a93db5ac1278 Remove Windows print dialog UI for selecting frameset behavior. r=bobowen https://hg.mozilla.org/integration/mozilla-inbound/rev/d9fe316eb3b4 Remove Linux print dialog UI for selecting frameset behavior. r=karlt
Comment 14•5 years ago
|
||
Pushed by jwatt@jwatt.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/be349ba27250 Stop setting frameset printing behavior for nsIPrintSettings::kRangeSelection. r=bobowen https://hg.mozilla.org/integration/mozilla-inbound/rev/618f6a8269ac Stop using GetHowToEnableFrameUI in nsPrintJob::EnablePOsForPrinting. r=bobowen
Comment 15•5 years ago
|
||
Pushed by jwatt@jwatt.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/a5cb405483b4 Reduce code duplication in nsPrintJob::EnablePOsForPrinting. r=bobowen https://hg.mozilla.org/integration/mozilla-inbound/rev/625e654f20a4 Remove internal code for various frameset printing behaviors. r=bobowen https://hg.mozilla.org/integration/mozilla-inbound/rev/784f254cebbc Remove printing related isFramesetDocument and isFramesetFrameSelected code. r=bobowen
Comment 16•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b58a59871bca
https://hg.mozilla.org/mozilla-central/rev/a93db5ac1278
https://hg.mozilla.org/mozilla-central/rev/d9fe316eb3b4
https://hg.mozilla.org/mozilla-central/rev/be349ba27250
https://hg.mozilla.org/mozilla-central/rev/618f6a8269ac
https://hg.mozilla.org/mozilla-central/rev/a5cb405483b4
https://hg.mozilla.org/mozilla-central/rev/625e654f20a4
https://hg.mozilla.org/mozilla-central/rev/784f254cebbc
Updated•5 years ago
|
Comment 17•5 years ago
•
|
||
Print dialog is not affected by the removal of the above specified options.
Confirming this issue as verified fixed on Windows 10x64 and Ubuntu 16.04x64 and macOS 10.14 with 69.0b8 and 70.0a1(2019-07-28)
Updated•5 years ago
|
Description
•