[wp-meta] [Making WordPress.org] #1379: Lost text without warning when click link in Trac without JavaScript enabled

[Making WordPress.org]

#1379: Lost text without warning when click link in Trac without JavaScript
enabled
-------------------------+------------------
  Reporter:  pdfernhout  |      Owner:
      Type:  defect      |     Status:  new
  Priority:  lowest      |  Component:  Trac
Resolution:              |   Keywords:
-------------------------+------------------
Changes (by pdfernhout):

 * priority:  normal => lowest


Comment:

 **tl;dr Going once... Going twice... Sold to the gentleman waving the
 noscript tag. :-)**

 @nacin Since no one else has expressed an opinion over the past ten days,
 and as you've made the case that multiple other Trac functions require
 JavaScript, I have to agree that what you outline to prevent Trac use
 without JavaScript sounds like like the most sensible approach -- subject
 to a couple of caveats, one technical concern, and a quibble. :-) And even
 a question, after reflection, that maybe it is not worth bothering about
 entirely.

 One caveat: would such an approach of requiring JavaScript prevent Trac
 issues from being indexed by search engines? Or would the content still be
 indexed OK even though it was overlayed with the noscript component? It
 seems like it is indexed according to
 [http://webmasters.stackexchange.com/questions/35939/is-hidden-content-
 display-none-indexed-by-search-engines this stackexchange post] which
 links to [http://seotesttool.com/blog/does-the-google-bot-index-css-
 hidden-divs/ this post] -- but people still seem a bit hesitant, in that
 search engines can change.

 To test the current behavior, I just searched on the title of this issue
 and
 [https://www.google.com/search?q=Lost+text+without+warning+when+click+link+in+Trac+without+JavaScript+enabled
 it showed up in Google]. Would that still happen with the approach you
 outline? I'm thinking it would since the rest of the page content would
 still be there as hidden text, but I am not sure that is true for all
 major search engines. That's assuming the code you supplied actually
 worked, but it may not (see the technical concern).

 Still, even if the content was not indexed (and it seems like it indeed
 will be), a different version of the page could be presented to web
 crawlers by the server -- although that is layering on server complexity.
 But at least indexing is not a showstopper in either case.

 By the way, the second Google match leads to this unresolved main Trac
 project issue from eleven(!) years ago
 [http://trac.edgewall.org/ticket/1437 "warn user about losing unsaved
 changes"]. There is a patch, but it requires JavaScript. :-) Apparently,
 back then Trac used with FireFox still preserved the contents when you
 pressed back, as it was an IE issue. At first I wondered if something has
 changed in the past decade either in Trac or just WordPress Trac so that
 FireFox does a refresh when you hit the back button to return to a Trac
 page? But perhaps this difference is explained by comment 8 there which
 says: "I would vote for this too; even Firefox won't cache the fields if
 you are running Trac on an SSL site. I just lost a large amount of work
 due to accidently clicking on a link when trying to return foreground
 window focus."

 When I try the link for this issue with plain http, Trac redirects the
 page to https, so I apparently can't test that the behavior might be
 different for FireFox not under https.

 Another caveat: users may be just browsing tickets instead of creating
 them. Are the 1200 lines of custom JavaScript for WordPress Trac related
 more towards editing than browsing? Is it reasonable to require users just
 browsing tickets to enable JavaScript if they don't really have to? What
 percentage of users just browse as opposed to edit? 50/50? 80/20? 99/1?
 Based on [http://stackoverflow.com/questions/9478737/browser-statistics-
 on-javascript-disabled this stackoverflow question from a couple of years
 ago] it seems almost certain only 1% of users will have JavaScript
 disabled no matter what they are doing.

 Ideally, it still might be interesting to look at WordPress Trac logs or
 maybe add some temporary instrumentation to Trac to check what percentage
 of users browse it without JavaScript enabled to verify that Stackoverflow
 discussion. But with time limits, it's hard to argue that is worthwhile to
 collect if we are almost certain its going to be around 1%. I can accept
 that percentage intellectually, even if personally as a long-time NoScript
 user I have a hard time emotionally understanding that. :-) Even under
 Chrome I've used HTTP Switchboard. But I can concede that is the way it
 is.

 One technical concern is that the specific code you specified still
 displayed content when I tried it in FireFox:
 {{{
 <html>
 <body>
 Lots of content here!!!
 <noscript><div
 style="width:100%;height:100%;position:fixed;background:#fff">Enable
 JavaScript</div></noscript>
 More content!!!
 </body>
 </html>
 }}}

 Here is an
 [https://github.com/pdfernhout/narrafirma/blob/v0.9.4/webapp/survey.html
 example] of some code I've previously written that starts out with the
 rest of the webapp either hidden or unpopulated so if JavaScript is not
 enabled nothing is displayed except what is in the noscript tag (and it
 also has flicker suppression on a please wait loading panel if the app
 loads quickly).

 Still, with additional CSS styling, perhaps your approach would work. No
 doubt you've done this before, but for anyone else, here is a useful
 [http://www.cssscript.com/minimal-modal-window-with-plain-javascript/ link
 on modal dialog styling]. I used that
 [https://github.com/pdfernhout/narrafirma/blob/v0.9.4/webapp/css/standard.css
 here].

 One minor quibble with the proposed solution: "Enable JavaScript" might
 perhaps be better as "Enable JavaScript to use Trac" or something else a
 little more explanatory and a little less demanding. As much as I love
 great JavaScript webapps, the shorter text could also be interpreted as a
 broad call for a person to enable JavaScript everywhere which is a
 potential increased security risk and privacy risk. Not that, as above,
 99% of people apparently care about that kind of thing. :-(

 BTW, it's been interesting to read up on the controversy you refer to
 about whether to open pages in new windows --
 [http://www.trilithium.com/johan/2005/03/target-blank/ one example];
 thanks. I can agree that controversy makes the new window approach
 problematical.

 If new windows are out, then unless JavaScript is required, that would
 leave figuring out why Trac refreshes in FireFox when I press the back
 button under https. I'm kind of assuming it is there for a reason though?

 So, because this is not a very important issue to me now that I understand
 it and can work around it by enabling JavaScript, I think the noscript
 solution is easiest give almost certainly 99% of users have JavaScript
 enabled -- although you'd probably want to use a slightly more
 sophisticated technical approach than your (undoubtedly joking) one liner.
 :-)  Or, maybe not, given one might expect the 1% with JavaScript turned
 off should be willing to deal with a little data loss now and then to keep
 them on their toes. :-)

 More seriously, if Trac main project hasn't cared much about this for
 eleven years, given other competing priorities, maybe it would be best to
 just reject this issue and move on. For now, I'm setting it to lowest
 priority.

--
Ticket URL: <https://meta.trac.wordpress.org/ticket/1379#comment:3>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org