Lost text without warning when click link in Trac without JavaScript enabled

[pdfernhout]

Expected Behavior: When JavaScript is not enabled, Trac should always either open links supplied by Trac in new pages, or Trac should preserve entered text when a user clicks the the back button after viewing a link supplied by Trac.

Observed behavior: If you do not have JavaScript enabled for the Trac page (like when using NoScript with FireFox), and enter a new issue in Trac, or enter an update an existing issue, and then click the Wiki Formatting link, you will proceed to that Wiki Formatting page, and when you press the back button, your entered text will be gone. That happened to me after entering the text for my first WordPress bug report when I was almost finished and I went to check a formatting issue. :-(

If you have JavaScript enabled, when you click the Wiki Formatting link (or presumably other links, but I have not tested them), you will instead receive a warning about possible data loss and will be asked to confirm you want to leave the page. That works well, but not everyone has JavaScript enabled everywhere. Trac seems to otherwise work without JavaScript.

The same issue applies for other links on that page. Of those, the search, contributor handbook, and Trac Tickets links are probably the most likely to be clicked on when working on a new ticket and thus lead to lost text.

I have only tested this in FireFox with NoScript, but I assume other browsers would act the same way without JavaScript enabled.

Possible solutions: I don't know the best way to deal with the issue, but one possibility is to open all of those links in new browser pages (at least when JavaScript is not enabled). That is probably the easiest fix. When JavaScript is enabled, those links could be rewritten to open in the same page if preserving the current behavior under JavaScript was desirable. Alternatively, Trac could require JavaScript to be enabled to use it, but that does not feel like a good choice to me for just this one issue given the previous option. Or, as another possibility, there may be something which could be changed that Trac is currently doing to reset the entered text or cause a page reload when re-visiting the page by using the back button; it is otherwise common to go back to a page with entered text in FireFox and have the entered text still be there.

[pdfernhout]

#1380 was marked as a duplicate.

[nacin]

I am inclined to just do this:

<noscript><div style="width:100%;height:100%;position:fixed;background:#fff">Enable JavaScript</div></noscript>

First, on the principle that in 2015 I cannot care about JavaScript disabled, *especially* when it's a web application/tool, and not just a random website.

Second, we enhance Trac with more than 1200 lines of out own custom JS. Practically speaking, it needs to be enabled.

Also — these are Trac's links, not our own. This open-in-a-new-window part is actually done by our custom JS. It could be reported upstream, but I'd also expect that any suggestion in an open source project of target="_blank" will turn into a flamewar.

[pdfernhout]

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 ​this stackexchange post which links to ​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 ​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 ​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 ​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 ​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 ​link on modal dialog styling. I used that ​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 -- ​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.

[pdfernhout]

Having reflected on this some more, here is an easily doable JavaScript proposal for WordPress Trac that would address the issue. If you look at a web page at TED without JavaScript, such as this one on ​the lost art of democratic debate, at the very top of the page on a contrasting color background it says:

You have JavaScript disabled
For the best experience, please turn JavaScript on. Here's how

That text has a link that goes to ​enable-javascript.com.

So, if JavaScript is so essential to WordPress Trac, I'd suggest a similar approach.

The approach I mentioned above that I use for a single page app that is completely dependent on JavaScript is probably not best here. While it could work, it would require changes to have all content either be hidden or be added at runtime, which would be an architectural change. Likewise, just preventing use of the entire application when it is otherwise usable for browsing, like via an overlay div that blocks access to underlying content, is also probably not best either.

One concern I see from more reflection is that even if only 1% of WordPress Trac users have JavaScript turned off like via NoScript (a guess, but we don't know for sure without quantified measurements), such techies may be a disproportionately higher percentage of Trac reporters than just 1%. Consider for example, as ​Melinda Varian documents, what happened when IBM announced on February 8, 1983 that it would go "Object Code Only (OCO)" with its mainframe VM (virtual machine) source code instead of keeping the previous policy of having the source code accessible to all licensed users. Those users (essentially anyone using an IBM mainframe), could share changes with other licensed users, forming the basis of a thriving community. The justification for OCO was in part that only a small percentage of the sites actually used the source code so access was not very important. I expect some lawyer or executive somewhere thought the benefits of preventing competitors gaining access to "secrets" would outweigh a very few unhappy users. Of course, those small number of sites that used the source code (Melinda Varian's Princeton University site was one of them) were the places that were continually fixing IBM's many bugs and providing various enhancements for free. That move has now been widely seen to have been a disaster for IBM as well as the VM community. IBM's move to supporting open source software in the 2000s was in part a reflection of that past experience as some long-time IBMers were still upset about that whole OCO decision (although obviously, industry trends with Linux played a part, too).

So, in this case, if it turns out WordPress developers are ten times more likely to use something like NoScript, HTTP Switchboard, uBlock Origin, uMatrix, or whatever than the typical WordPress user, then one might find that 10% of Trac reporters are affected by this issue, which is then not insignificant. That's all speculation without metrics though.

So, while it can be hard to prioritize the needs of a few when there are so many other things to be done affecting so many users, just because only 1% of some pool of users may benefit from a feature does not necessarily mean that only 1% of the community will be affected by its removal or change. It really depends on the specific feature and the context and the specific users and their roles in the community. So, based on that reasoning, and now that I also have a plausible easy-to-make change to suggest with the TED site example, I'm bumping the priority back up to "normal". :-) People should feel free to bump it back down of course; I may be totally wrong.

[obenland]

Providing fallbacks for users with JavaScript disabled is probably not the best use of Meta's time. I'm fine with that being an entry requirement to helping out with WordPress.