Closed Bug 1565129 Opened 3 months ago Closed 3 months ago

plain_text.wrap_long_lines no longer working as before

Categories

(Core :: Layout, defect)

68 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- fixed
firefox68 --- wontfix
firefox69 --- fixed
firefox70 --- fixed

People

(Reporter: software, Assigned: emilio)

References

(Regression, )

Details

(Keywords: regression)

Attachments

(2 files)

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

Steps to reproduce:

I updated to Firefox 68 today on my Windows 10 PC. Afterward, I opened a browser tab containing a plain text, online log file containing hundreds of individual lines of data. The entries were wrapped across lines and there was no horizontal scrollbar.

I checked my "about:config" settings and the key, "plain_text.wrap_long_lines" was still set to my preferred setting of "false." I toggled the value, closed and restarted the browser several times, clearing the cache, but the text lines continue to wrap, ignoring my preference (to not wrap).

The "View" > "Page Style" settings had no affect on the plain text page.

Actual results:

Before the update to Firefox 68, plain text long lines were not wrapped, as per my preferences. Firefox 68 is ignoring my text wrap preference and is forcing the text to wrap on pages I specifically don't want to wrap.

Expected results:

The plain text online document should have displayed all lines of results in long individual lines, with a horizontal scrollbar to view long lines.

I can reproduce the issue on Nightly70.0a1 Windows10.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5f58e2f5d1f75f42edea41b1015a6037fe7764c3&tochange=5df5f0db2284956f3afe587cc931d471051d8700

Regressed by: 5df5f0db2284956f3afe587cc931d471051d8700 Emilio Cobos Álvarez — Bug 1514655 - Always wrap plain text documents. r=bzbarsky

Product: Firefox → Core
Regressed by: 1514655
Component: Untriaged → Layout

That pref was removed in that bug due to web compat issues. But I guess it's still useful for top-level documents.

Using an user stylesheet is a better solution, though I guess it's reasonable to add that pref back, or an alternate stylesheet that you could enable using the Page Style menu.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

That pref was removed in that bug due to web compat issues. But I guess it's still useful for top-level documents.

Using an user stylesheet is a better solution, though I guess it's reasonable to add that pref back, or an alternate stylesheet that you could enable using the Page Style menu.

That alternate stylesheet option probably won't work for common users like me. I am not a browser extension developer. I just use Firefox because I prefer it over other browsers (for its customizability and tab appearance and scrolling tabs) and can sync logins and visited sites across multiple computers. For most of us "users," finding and changing a menu > View setting is as deep as we care to go. I did look to see if Word Wrap was an option and it is not. I learned abut using "about:config" to customize things from online tutorials.

As a "user," I would like to see the nowrap preference reactivated. What would it hurt? The default is "off" anyway. I don't even know how to add a stylesheet to Firefox, but I can learn to if I must.

FYI: the page that got broken by this bug (that apparently isn't a bug!) is my real time online raw access log which I read to catch spam and exploit attempts in near real time. This log is used to update IP blocklists used around the World. Unwrapped long lines are easier to read for me.

Looks like some users use it, and it's not too much effort to support. This is
somewhat simpler, and IMO better than what existed before bug 1514655 because:

  • It doesn't regress bidi rendering when the pref is disabled (before, the pref
    would prevent plaintext.css from applying altogether).

  • It's consistent with the way view-source docs work.

  • It doesn't use non-standard stylesheet APIs to toggle the stylesheet
    (bug 1260720).

Assignee: nobody → emilio
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6f468ad73df2
Re-introduce plain_text.wrap_long_lines. r=bzbarsky

Backed out changeset 6f468ad73df2 (Bug 1565129) for causing leaks

Backout link: https://hg.mozilla.org/integration/autoland/rev/d9a9c5993b8cc62d1a221dea3d591311ed708974

Did this backout on Emilio's request (on irc), no failure atm.

Flags: needinfo?(emilio)
Flags: needinfo?(emilio)

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=255999527&repo=autoland&lineNumber=19866

18:53:58 INFO - TEST-PASS | leakcheck | tab no leaks detected!
18:53:58 INFO - leakcheck | Processing leak log file /var/folders/gg/9f83l6ld4933gksk18d5s21m00000x/T/tmpvs6S7R.mozrunner/runtests_leaks_tab_pid1201.log
18:53:58 INFO -
18:53:58 INFO - == BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS, tab process 1201
18:53:58 INFO -
18:53:58 INFO - |<----------------Class--------------->|<-----Bytes------>|<----Objects---->|
18:53:58 INFO - | | Per-Inst Leaked| Total Rem|
18:53:58 INFO - 0 |TOTAL | 40 392| 186421 2|
18:53:58 INFO - 814 |nsHtml5HtmlAttributes | 384 384| 14 1|
18:53:58 INFO - 982 |nsTArray_base | 8 8| 67970 1|
18:53:58 INFO -
18:53:58 INFO - nsTraceRefcnt::DumpStatistics: 1031 entries
18:53:58 INFO - TEST-INFO | leakcheck | tab leaked 1 nsHtml5HtmlAttributes
18:53:58 INFO - TEST-INFO | leakcheck | tab leaked 1 nsTArray_base
18:53:58 INFO - TEST-UNEXPECTED-FAIL | leakcheck | tab 392 bytes leaked (nsHtml5HtmlAttributes, nsTArray_base)
18:53:58 INFO -
18:53:58 INFO - leakcheck | Processing leak log file /var/folders/gg/9f83l6ld4933gksk18d5s21m00000x/T/tmpvs6S7R.mozrunner/runtests_leaks_tab_pid1202.log
18:53:58 INFO -
18:53:58 INFO - == BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS, tab process 1202
18:53:58 INFO -
18:53:58 INFO - |<----------------Class--------------->|<-----Bytes------>|<----Objects---->|
18:53:58 INFO - | | Per-Inst Leaked| Total Rem|
18:53:58 INFO - 0 |TOTAL | 30 0| 746779 0|
18:53:58 INFO -
18:53:58 INFO - nsTraceRefcnt::DumpStatistics: 1004 entries
18:53:58 INFO - TEST-PASS | leakcheck | tab no leaks detected!
18:53:58 INFO - leakcheck | Processing leak log file /var/folders/gg/9f83l6ld4933gksk18d5s21m00000x/T/tmpvs6S7R.mozrunner/runtests_leaks_tab_pid1203.log
...
18:58:35 INFO - TEST-PASS | leakcheck | tab no leaks detected!
18:58:35 INFO - leakcheck | Processing leak log file /var/folders/gg/9f83l6ld4933gksk18d5s21m00000x/T/tmpMTtHd5.mozrunner/runtests_leaks_tab_pid1335.log
18:58:35 INFO -
18:58:35 INFO - == BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS, tab process 1335
18:58:35 INFO -
18:58:35 INFO - |<----------------Class--------------->|<-----Bytes------>|<----Objects---->|
18:58:35 INFO - | | Per-Inst Leaked| Total Rem|
18:58:35 INFO - 0 |TOTAL | 44 392| 214845 2|
18:58:35 INFO - 799 |nsHtml5HtmlAttributes | 384 384| 10 1|
18:58:35 INFO - 961 |nsTArray_base | 8 8| 78458 1|
18:58:35 INFO -
18:58:35 INFO - nsTraceRefcnt::DumpStatistics: 1010 entries
18:58:35 INFO - TEST-INFO | leakcheck | tab leaked 1 nsHtml5HtmlAttributes
18:58:35 INFO - TEST-INFO | leakcheck | tab leaked 1 nsTArray_base
18:58:35 INFO - TEST-UNEXPECTED-FAIL | leakcheck | tab 392 bytes leaked (nsHtml5HtmlAttributes, nsTArray_base)
18:58:35 INFO -
18:58:35 INFO - leakcheck | Processing leak log file /var/folders/gg/9f83l6ld4933gksk18d5s21m00000x/T/tmpMTtHd5.mozrunner/runtests_leaks_tab_pid1336.log
18:58:35 INFO -
18:58:35 INFO - == BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS, tab process 1336
18:58:35 INFO -
18:58:35 INFO - |<----------------Class--------------->|<-----Bytes------>|<----Objects---->|
18:58:35 INFO - | | Per-Inst Leaked| Total Rem|
18:58:35 INFO - 0 |TOTAL | 38 0| 627078 0|
18:58:35 INFO -
18:58:35 INFO - nsTraceRefcnt::DumpStatistics: 934 entries
18:58:35 INFO - TEST-PASS | leakcheck | tab no leaks detected!
18:58:35 INFO - leakcheck | Processing leak log file /var/folders/gg/9f83l6ld4933gksk18d5s21m00000x/T/tmpMTtHd5.mozrunner/runtests_leaks_tab_pid1337.log

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/16bc2f5a8e19
Re-introduce plain_text.wrap_long_lines. r=bzbarsky

I have created a custom stylesheet, userContent.css, and placed it inside a new sub-directory in my Firefox profile, named "chrome." Following a tutorial and W3C I added code for a specific URL to be given "white-space: nowrap. It failed to have any effect. The code is below.

@document url("ftp://ftp.REDACTED/") {

  • {white-space: nowrap;}
    }
    Is the code ineffective because it is in the wrong place, has the wrong file name, or its functionality has been disallowed? Or, is it a bad CSS directive?
  • @document has not been standardized. You will have to use @-moz-document.
  • Probably you want white-space: pre instead of white-space: nowrap.
  • Also probably url should be url-prefix. Otherwise it will only match the exact URL.

(In reply to Masatoshi Kimura [:emk] from comment #12)

  • Also probably url should be url-prefix. Otherwise it will only match the exact URL.

Masatoshi;
Thank you for your suggestions. I tried all variations of the css codes and even tried to change the font and background colors, all with no effect. Do these css stylesheets apply to the consumer version of Firefox, or just Web Dev versions? I have the consumer version.

I thought I would add that the nowrap config setting does work when I use "View Page Source" to read my online logs. This is the setting key: "view_source.wrap_long_lines" which defaults to False.

I am using this to read my logs until the bug is fixed. I find this curious...

It should apply everywhere, but given the plaintext.css is loaded as a document stylesheet, you probably want to use !important:

@-moz-document url-prefix("ftp://ftp.REDACTED/") {
    pre { white-space: pre !important }
}
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Duplicate of this bug: 1565989

I see this bug has affected other Firefox 68 users. I have a temporary workaround using a custom user css file. It took some playing around to get it working, but, once you discover the actual URL to the affected plain text pages (e.g., access logs), these codes will force plain text documents to appear on long lines without word wrap.

@-moz-document url-prefix("ftp://DOMAIN_log") {

  • { white-space: pre !important }
    }

I used an asterisk * as a universal selector because plain text logs have no HTML elements. The * tells the browser to apply the styles to all elements, including undeclared elements. The URL was tricky and threw me ofrf for a day or two. I learned the actual URL by using the right click option: View Page Source. The full URL was there. I copied just the first part, before the login details and applied it. The qualifier URL-PREFIX ensures that everything that follows will be included, even though it isn't typed into the code.

The !important is used to override plaintext.css.

IHTH.

I see this bug has affected other Firefox 68 users. I have a temporary workaround using a custom user css file (detailed in a previous reply). It took some playing around to get it working, but, once you discover the actual URL to the affected plain text pages (e.g., access logs), these codes will force plain text documents to appear on long lines without word wrap.

@-moz-document url-prefix("ftp://DOMAIN_log") {

  • { white-space: pre !important }
    }

I used an asterisk * as a universal selector because plain text logs have no HTML elements. The * tells the browser to apply the styles to all elements, including undeclared elements. The URL was tricky and threw me off for a day or two. I learned the actual URL by using the right click option: View Page Source. The full URL was there. I copied just the first part, before the login details and applied it. The qualifier URL-PREFIX ensures that everything that follows will be included, even though it isn't typed into the code.

The !important is used to override plaintext.css taht gets loaded first.

IHTH.

Did you want to nominate this for Beta & ESR68 uplift?

Flags: needinfo?(emilio)

Comment on attachment 9077427 [details]
Bug 1565129 - Re-introduce plain_text.wrap_long_lines. r=bzbarsky

Beta/Release Uplift Approval Request

  • User impact if declined: There's no simple way to make plaintext document not wrap long lines.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Code disabled by default, and relatively straight-forward.
  • String changes made/needed: none
Flags: needinfo?(emilio)
Attachment #9077427 - Flags: approval-mozilla-release?
Attachment #9077427 - Flags: approval-mozilla-beta?

Comment on attachment 9077427 [details]
Bug 1565129 - Re-introduce plain_text.wrap_long_lines. r=bzbarsky

Adds back the ability to wrap long lines in plaintext documents via a non-default pref. Approved for 69.0b8. I don't think we need to worry about this for a 68 dot release, however.

Emilio, is this something we'll want to fix on ESR68, though? I could see this being potentially something enterprises could care about. If so, it'll need a rebased patch, however.

Flags: needinfo?(emilio)
Attachment #9077427 - Flags: approval-mozilla-release?
Attachment #9077427 - Flags: approval-mozilla-release-
Attachment #9077427 - Flags: approval-mozilla-beta?
Attachment #9077427 - Flags: approval-mozilla-beta+
Attached patch ESR rebase.Splinter Review

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: See comment 21
  • User impact if declined: See comment 21
  • Fix Landed on Version: 70
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Disabled by default, relatively simple.
  • String or UUID changes made by this patch: none
Flags: needinfo?(emilio)
Attachment #9080142 - Flags: approval-mozilla-esr68?
Comment on attachment 9080142 [details] [diff] [review]
ESR rebase.

Approved for 68.1esr in case this is something enterprises might care about. Not sure if we need to do anything policy-wise for this pref besides having it be available for setting, though.
Attachment #9080142 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+

Definitely seems like something to backport to esr68.

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