Mathwiz

Hope you're feeling better, and that there were no after-effects! I've been one of the lucky few not to have had a Covid infection yet (AFAIK; I understand some infections are asymptomatic), but many of the folks I know have had it. Aw, man; I have Spectrum Internet too - and Spectrum Mobile! The mobile account is on auto-pay, and I generally pay the Internet account by mail, so I haven't needed to pay online in a while. I guess if I do need it, I'll go for 360EE....

I followed your links and downloaded the Custom Buttons extension. Its install.rdf file tops out at Firefox 48, so to install it in either Serpent version, you need to modify that, since Serpent uses the Firefox app ID. I changed it to 55.* and it installed OK in St 55. I'm presuming the same change will let it install in St 52 as well; I'll test that later if I get some time. The only odd thing I found was that I had to restart Serpent 55 twice before it was ready to go. Next, I went to that link, but this is all I saw: So yes, it appears you've created the necessary custom button, but there's no code, no link, nothing to test in Custom Buttons at that post. Anyway, it's no big deal. I was only "asking for a friend," but can't remember who, because the original question was from My Browser Builds part 3, and now that that thread has been closed, the board doesn't let you quote from it as easily (no "Quote" prompt shows up when selecting text) so I just copied it and pasted into a quote block.

Of course! It was so obvious! Why didn't anyone think of that before? But seriously, thanks @luweitest for not only finding the preconditions that trigger this bug, but also digging into the commits to find out what changed and how to reverse it!

Yes, and despite all my complaints about the company, Google still has a pretty good search engine (both unnecessary in this case since @dmiranda answered the question almost immediately after it was raised). But a post answering a rhetorical question is usually meant to point out that the answer was not as obvious as the person asking it seemed to think it was! It's not as if we all read @UCyborg's post, slapped our foreheads, and thought, "Of course! Just set browser.backspace-action to 2! It was so obvious! Why didn't anyone think of that before, instead of suggesting all those Greasemonkey scripts?" At any rate, another little browser annoyance gone. No more hitting backspace after an unintended mouse click outside the comment posting window and losing everything! And while we're on the subject, what exactly did "issue 2019" fix? Is it related to the backspace bug, as @luweitest speculated? (And for the uninitiated - i.e., me - how does one search for "issue 2019" upstream so I don't have to keep asking @VistaLover for the answer?)

No human-readable checkbox AFAIK, but there is a Boolean setting in about:config. media.autoplay.enabled; defaults to false in St 55 (not sure of the default in St 52). I suspect a good JavaScript programmer (@AstroSkipper?) could rig up a custom button to toggle that setting! Probably because even if one were lucky enough to find it, it's an integer pref and it's not at all clear what 0 does, 1 does, 2 does, etc. Luckily we have @dmiranda: The bug discussed above aside, I too have found the default behavior (backspace=page back) to be worse than useless, so I changed my setting to 2. It's way too easy to have the focus in the wrong place by accident, press that key, and lose everything you typed! If I wanted "page back" assigned to a key at all, it'd probably be F12, or maybe "Previous Track" on "multimedia" keyboards that have that key, but certainly not backspace!

That's a good idea, @Dave-H! I always bristled a bit at the "abruptness" of the switchover from one "My Browser Builds" thread to the next. It makes more sense to start the next thread with the next set of builds. To be clear (and fair to Google), it's not so much their Chromium engine (I use Chromium-based browsers - albeit "unGoogled" - when necessary) as it is Google's "predatory innovation" cycle: Google thinks up new "features" that Javascript "needs." (And again to be fair, these "features" often are real improvements that make Javascript programming a bit easier for Web developers - but that's not the point of them.) Google updates Chromium (and Mozilla and Safari update their own Javascript engines) to correctly interpret the new "features," so if you stay current on Safari, Firefox, SeaMonkey, or one of the many Chromium-based browsers, nothing ever seems amiss. Google and "friends" (e.g., Microsoft) then use the new "features" as much as humanly possible, not only on their own Web sites (e.g., GitHub), but also in the "frameworks" used by most Web sites these days. (Nobody codes entire Web sites in raw HTML and CSS anymore; it's too labor-intensive. Everyone uses frameworks.) Web developers update their sites to use the new "frameworks" - often unwittingly, as they may simply link to a CDN that always serves, say, the latest JQuery version. Even if browser developers outside the "Goog collective" (like, say, MCP) are able to add support for the latest Javascript "features," by the time they do, so the cycle begins again, thus preserving the Apple/Google/Microsoft/Mozilla oligopoly.

I'm sorry, but that just makes no sense at all. IE was alive and well less than 10 years ago in 2013, when IE 11 was released for Windows 7 and 8.1. Officially, IE was replaced by Edge in 2015 with the release of Windows 10, but if IE had used a "major.minor" version numbering system like most software, Edge would probably have just been the next "major" version of IE. With the "major only" version numbers all the big Web browsers have chosen to curse themselves with, though, "IE 12" just didn't capture the extent of changes from IE 11; hence the new name and logo (which looked much like the old IE logo). BTW, Edge's new UI looked more like Chrome than Firefox. (In 2015, Firefox looked like Pale Moon does now.) So "classic" Edge is really just the final version of IE. Web designers test their designs on all major browsers: Chrome, Firefox, Edge, and, until recently, IE. What actually killed IE off was the same thing that now bedevils us: IE 11 couldn't handle all the Googlescript showing up in Web site frameworks, and classic Edge took a lot of development to keep up. Microsoft didn't want to spend money chasing Chrome, so in 2019 Microsoft released "New Edge" based on Google's Chromium. (You'll get the references if you were drinking American soft drinks in 1986.) Even the logo changed to some kind of ambiguous e/c blend, to signify the Pepsi - I mean Chromium - in Edge! This was the cause of IE's death, not Mozilla-loving Web designers casting shade on it back in the Bush Administration. And in late 2017, Mozilla switched Firefox to Quantum and the Photon UI, making it a rather obvious Chromium clone. "New Firefox" now lives in name only! Sure, it renders all the latest Googlized Web sites perfectly, but it tastes just like Chrome! So if Mozilla were somehow responsible for IE's death, it took them so long to carry out the murder that their own products died off first! No. The evidence is much stronger that it was Google that drove both Microsoft and Mozilla to abandon their own code bases. IE's code was proprietary, and so is locked away in a Microsoft safe somewhere. But thanks to Mozilla, at least Firefox's abandoned code base lives on in the UXP platform.

OK, that makes sense. I've certainly done that myself when copying and modifying code - leaving no-longer-needed chunks in. If they don't do any apparent harm there's no reason for me to hunt them down and take them out!

IMO the key date for determining "obsolescence" isn't when the product was first released; it's when the product was last supported/updated. Which, for the POSReady '09 "flavor" of XP, was 2019. Although to be fair, POSReady '09 wasn't intended to be used for Web browsing, so perhaps we should use 2014. So yeah, it's "obsolete," but hardly as ancient as the quoted factoid is trying so hard to make it sound. Yes, I tend to agree. Here, the unwanted behavior is triggered by a CSS property that's "supposed to be" ignored? So why is the Web site sending it in the first place? The only effect of not sending it would be that it would work on older Firefox-based browsers. So this smells like intentional breakage. Although, to be fair, probably not by the Web site designer, but rather by the framework used to build the site.

This (regexp groups) is becoming an issue on more and more web sites. Question for those who frequent the upstream forums: Has there been any progress on dealing with this, or is it a "toughie" like Web Components seems to be?

A slow Internet and/or computer can be signs of malware on your PC, including "bot malware" (by which I think they mean something like the infamous Back Orifice, intended for hackers to use your computer, by remote control, to secretly do things like attack other computers) or at least, a noticeable decrease in speed can be signs of such. (You, the user, would of course be best positioned to notice such a decrease. All Cloudflare can tell is that your computer/Internet connection are slower than it considers typical.) But to be blunt, I think Cloudflare couldn't possibly care less whether your PC or mine has a malware infestation, unless said malware is being used to attack one of their paying clients, like @AstroSkipper's movie ticket site. The purpose of the "security check" is to protect their customer, not you. So I hope they presented that message merely as a courtesy while you waited for the final result of their "security check." Of course, your browser didn't fail the check outright; CF ended up passing the question on to "hCAPTCHA" for a final determination. (BTW, "hCAPTCHA" is new to me. Well, at least they didn't rely on Google!) But even if your browser had been fast enough not to have received that message, I think you still would've gotten the CAPTCHA, unless CF's algorithm amounts to, "If this goes really fast, it couldn't possibly be a bot, so no reason for a CAPTCHA. But if it goes slowly, well, then 'bot malware' might be involved - better send a CAPTCHA just to be sure!" In the unlikely case that this is CF's algorithm, I think it's a pretty stupid one, since the whole point of a bot is to do things faster than humans!

WRP might be useful for some environments, but ... ... so it might solve @Dave-H's conundrum, since we know he has a PC that can run Windows 10; thus, has at least one PC in his home network that can run "modern" Chromium. It also solves any security concerns with FF 52.9, and would even let him use FF Sync! (He'd have to set FF to bypass the proxy for the FF sync server, of course.) But I don't think WRP can do everything. For instance, I don't think image maps can emulate the "hover" functionality of many sites, where (for instance) a menu drops down when you merely move the mouse over the top of the menu without clicking. (Try it with the "Activity" and "Browse" menus at the top of MSFN.org, and see. Maybe WRP is smarter than I'm giving it credit for, but I don't think they will drop down with WRP without clicking on them, and clicking will likely perform an unwanted action.) More to the point, many folks are running older browsers on older OSes because they simply can't afford a new PC that can run modern ones! WRP won't help them.

Seems to be another recurring issue. We last encountered it last May: The "non-interactive JS challenge" GitLab are sending, as part of their CloudFlare protection, is meant to work on only the major villains, i.e. Chrome and "buddies" ... That article was last modified a month ago, possibly the same time GL log-in became broken... And it would seem that User-Agent-Sniffin' does play a role, in the initial detection at least, according to: https://support.cloudflare.com/hc/en-us/articles/204191238-What-are-the-types-of-Threats-#bad-browser The problem from back then (May 5) was eventually resolved by NM 28.10.6a1: But, from @AstroSkipper's post, it looks like Cloudflare has "fixed" their challenge to once again block NM (probably official PM too). AIUI, Cloudflare just out-and-out blocks certain user agents "abused most commonly by spammers," but if you spoof a modern browser (Chrome on my Android is up to version 105 now), Cloudflare will send Javascript that only a modern browser can pass. What to do? Well, first, make sure it's not just a regression: download and try the previous NM version. If it works, report back here. But that probably won't work. Next step is for someone to try official PM. If, as I suspect, it doesn't work there either, know that upstream will be working on it, so 28.10.7a1 will likely resolve the issue. (Not much comfort in the meantime, I realize.) In the meantime, or if all else fails, your best option would be to find a UA that is neither "abused most commonly by spammers" (whatever that means) nor that of a modern browser, in the hopes that Cloudflare will then send you a CAPTCHA. You'd then have to solve an annoying CAPTCHA (and likely provide Google some unpaid labor) but at least you could sign in. Edit: Well, once again, @VistaLover beat me to it, although I suspect he worked longer on his post than I did on mine! Anyway, using Serpent 52 (and presumably its default UA) he did eventually receive the annoying CAPTCHA, which apparently he didn't have to solve manually. (Cloudflare may not like his PC, but Google was apparently satisfied that he wasn't a bot.) BTW, does anyone besides me find it, well, just plain stupid that Cloudflare thinks you may be a bot if your PC is too slow? What would be the point of using a bot that's slower than a human anyway? If it's that slow, you could just pay some impoverished third-world resident to do the same work, and (s)he could solve all the CAPTCHAs your site could manage. Edit 2: Or not - it just occurred to me that many of Google's CAPTCHAs are rather specific to modern Euro-American culture, so maybe a third-world resident couldn't solve them so easily; I don't know for sure....

In the interest of choice, Serpent (Australis interface) offers yet another solution: open about:about in a tab, then pin the tab! BTW, when using my pinned tab, I prefer to right-click, then open my chosen about: page in a new tab. That way I don't have to remember to go back to the previous page when I'm done.

Thank you; I wanted to make sure I wasn't just overlooking it. Back when Serpent was new, both versions (52 and 55) had support for Sync, so at least back then - 2018 or so - it just got included by default in Firefox forks like Basilisk/Serpent. So it seems to me that if it isn't in MyPal 68, its absence is likely deliberate. I just don't know whether it's deliberate on Feodor2's part or on Mozilla's part. It could be that Feodor2 removed it to avoid licensing issues with Mozilla, or it could be that Mozilla changed the source so that unbranded/rebranded forks no longer contain Sync by default. But it's not that big of a deal. I'm just curious, and I'm sure Feodor2 has bigger issues to contend with (MyPal 68 is still in beta).

I just learned a new trick I've been using the "Open With" extension for some time to simplify my Web browsing in Serpent. I normally use a profile with multiprocess mode enabled, but when I come across a link that requires a polyfill (such as GitHub, GitLab, etc.), I need to open a new browser window using my single-process mode profile. So I set up Open With to give me a menu option to do that. But there was a restriction. I always wanted the ability to run Serpent 55 from Serpent 52 or vice versa; but if I tried, even though I specified the correct path to the "other" Serpent, it would always open up the version I was running again. Weird. Well, I just found a workaround. Unfortunately it only works on 64-bit OSes, but it turns out that, if I'm running, say, 32-bit St 55, I can open 64-bit St 52! I just have to specify the path to the 64-bit version in Open With. Example entry: (They are truncated a bit in the above snip; the end of the command is of course basilisk.exe, and the end of the argument is -no-remote. I haven't tested every combination yet, but I assume it will work in reverse; i.e., if I'm running 64-bit St 55, I can open 32-bit St 52, and vice versa. One "gotcha," though, is that while folder names are not case-sensitive, profile names are! So make sure you get the case after the -P flag exactly right; otherwise you'll get the "Choose Profile" prompt instead of launching directly into your desired profile.

Well, of course, not 10 minutes after I posted the above, I found a new potential issue. Is anyone able to expand a long quote? For instance, this quote should "fade out" after a few lines, with an "expand" button at the bottom to reveal the whole quote. Does the "expand" button work with older browsers? For me on Serpent 55, it appears to work inconsistently; i.e., I can expand the quote below, but not some others:

It appears that the site issues that prompted this thread have been resolved. You could ask @xper, but there may be nothing more to discuss about the original topic. As such, you may wish to close this thread to further replies. Although I wouldn't object to having the last several posts moved to a new thread about browser sync systems. Up to you; it's fine with me either way.

Not sure, but the topic came up recently in another thread, and this seems like the appropriate place to ask: Was support for Firefox Sync removed from MyPal 68? I looked around and couldn't find it, but the Photon UI is so Chrome-like (and Australis-unlike) I could easily have missed it. If it was removed, was it because of a requirement under the MPL?

As you may know, Martok has just released Palefill 1.20. Since he has unfortunately declined to update Palefill to support www.ING.de, users of that web site will have to follow the above instructions themselves (do not key in the +'s; those merely indicate added lines) in order to use www.ING.de with Palefill 1.20 or subsequent releases. Oh, and by the way, GitHub is partially broken again with Palefill 1.19 or 1.20, at least when force-installed in Serpent 55. (Edit: Palefill 1.20 does seem to be doing the job in IceApe, so this must be an incompatibility between Palefill and St 55. GitLab is still working fine in St 55 though, so Palefill must be doing something right!) I swear, Micro$oft must require its GitHub developers to shoehorn in at least one use of every newly-announced Javascript feature, so that something on GitHub will break every time Google thinks up anything new! Luckily, downloading new releases still works (for now).

Me too! But if I did want a sync service and were free to pick one, PM Sync is more secure (there's that word again), and both are free, so all else being equal I'd choose PM Sync. If one were very ambitious (and had enough free time and programming skill) the best solution might be to add code to, say, St 52, offering a choice of PM Sync or FF Sync. That way, if you (a) wanted a sync service and (b) used FF on other platforms, you could choose FF sync; if (a) applied but not (b) you could choose PM sync. Best of both worlds!

I've always understood the word "insecure" to mean "not" secure vs. "less" secure; that's why I would've used the latter wording. But as you say, it's linguistic hair-splitting; hardly worth arguing about. A more interesting question is whether it's possible to restore Firefox Sync functionality to either version of Serpent. In the case of St 52, this would involve reverting some very old changes, which sounds risky: no telling what subsequent changes would be rolled back in the attempt. And St 52 users may be using Palemoon Sync now, and wouldn't want to lose that functionality. So probably best to leave St 52 alone, at least unless MCP blocks it from accessing Palemoon Sync. But St 55 still has the original Sync functionality it inherited from FF 53; it just doesn't seem to work for some reason. It may be feasible to fix Sync in St 55. Another possibility that comes to mind is MyPal 68; an XP-compatible FF 68 fork that may support FF Sync. (I haven't tried it.) Either could be the ultimate answer to @Dave-H's conundrum, since he could then use St 55 or MyPal 68 on XP, and Firefox on his other platforms, and could browse most modern Web sites, even on XP, without having to move to 360EE and lose Sync functionality.

I had to go back to that post because I honestly didn't remember reading anything about Basilisk being sold to a new developer, and when I got there, I saw why: There just isn't much to that post - mostly just "wow" without explaining what was so "wow"-worthy - and I'm not in the habit of clicking blind links just because someone says "wow." Basilisk wasn't even mentioned until the very last word - and that was in a quote about removing telemetry from Basilisk with no obvious relation to the rest of the post. Which brings up an MSFN question. When you post a link on MSFN to another MSFN post, MSFN "unfurls" it by default, providing a brief preview (although for some reason it didn't do so in @VistaLover's post). Does MSFN provide a way to similarly "unfurl" a link to a "foreign" site like palemoon.org? I've seen that feature at other fora, and it would've been quite useful in @XPerceniol's post. Thank you! This is actually such a simple solution to the branding issue I'm surprised no one thought of it earlier. Not that it would have satisfied the previous owners, but still, thanks again! I'm betting it's upstream, and that @roytam1 didn't even know about it. I'm also betting upstream couldn't possibly care less about our issues with the change. Perhaps @roytam1 could restore the original profile location; OTOH, deliberately forcing the path in MailNews back to "Binary Outcast\Interlink" would likely be viewed by upstream as trademark infringement. So perhaps it's best to live with it as is, particularly since you found a workaround.

So (official) Basilisk lives again, under new management! I guess money talks. Official Basilisk doesn't run on the "older OSes" that are the focus of this subforum; still, I'm surprised. I don't remember reading anything about this news before now. I do hope the new owner is less hostile to XP/Vista forks than MCP was. He did say to a Mac developer: ... which is encouraging. @roytam1's Serpent has diverged from official Basilisk in several ways other than retaining XP support, since Roytam also retained support that MCP removed for e10s, WebExtension add-ons, container tabs, and possibly lots of other stuff I'm forgetting. Still, it's nice to know there's an "upstream" again.

Come to think of it, even the word "insecure" overstates the case against FF 52.9. I'd probably describe it as merely "less secure" than 360EE, MyPal 68, and UXP-based browsers. WinXP is even older, of course, but we XP users got security updates through 2019, thanks to the POSReady hack. So strictly speaking, I guess FF 52.9 is even more out of date than XP itself! That said, the security risks involved are similar. IMO, they exist, but aren't terribly significant for most purposes. The best reason to move on from FF 52.9 is the one @Dave-H himself just gave; it just doesn't work well with the modern Web any more.