Mathwiz
Content Type
Profiles
Forums
Events
Posts posted by Mathwiz
-
-
I hate things like that. Whose side is the browser on, anyway? If it can download an image for display, it should be able to download the same image to disk.
Win 7+ (maybe Vista too; IDK) have a "snipping tool" you can use to save images, but I don't know if there's an XP app that does something similar.0 -
Here's part of what @VistaLover wrote recently about NM 27 vs. 28. Actually this was in the context of discussing why we were getting so many NM 27 updates:
On 2/19/2024 at 9:27 AM, VistaLover said:When upstream (MCP) abandoned Tycho (and PM27), roytam1 chose to keep his forked platform and browser (NM27) for the sake of Win2k/XP users on very old H/W, that doesn't support the SSE2+ instruction set ; as of this writing, NM27 and its browser engine, Goanna 3, is being "updated" based on a new "upstream", the developer (rmottola) behind the Artic-Fox project; this project aims to develop a (semi-)usable browser on old Macs, unsupported by Apple and the mainstream browser vendors; the project strives to "uplift" the browser from a Mozilla 38 platform snapshot (like in PM27/Tycho) to more recent versions, hence the large number of weekly updates (there's a lot of catching-up to do
when you're still at a Fx mid-40s level) ...
Also, Arctic-Fox isn't New Moon 27, hence several bugs that plague the latter are being reported by (the few?) NM27 users... To put it bluntly, I have now no need for this fork, because its web-compatibility is severely impaired in 2024; in addition to that, Roy is publishing SSE-compatible builds of NM28+St52, so if your old H/W can cope, it's advisable you use these instead of NM27...
NM27 has inherited from PM27 a "status-4-ever" internal component, but as the platform is being updated by rmottola to Fx43+, this component has been partially BROKEN, breaking with it several download-related functions/extensions/userstyles/userscripts etc.; I have kept, for archival purposes, a NM27 build from 20220812, which seems to be the last with no such issues...
As for NM28 (and St52), this is being updated mostly by backporting MCP code, especially in the platform aspect of it, and occasionally PM-specific (and Bk-specific) code is also being backported; and don't let the appVersion (28) confuse you
; Roy, for reasons he has explained in the past, decided to "freeze" the major version at 28, but latest NM28 embeds platform code to be found even in the latest PM33 "official" release ...
4 -
6 hours ago, AstroSkipper said:
A much more fundamental problem is the seemingly lost ability to carry out in-depth research in a forum before asking questions whose answer is actually easy to find.
Presumably because it's more convenient that way. And who wants to go through four threads with 200 pages each and then this one here with the help of the forum search? 
Forum search functions generally suck - not just ours but every one I've ever tried. What would be really helpful is Bing's new AI search - just type in the question, et voila! But you have to be running Edge to use it
and if you're able to do that, you probably aren't interested in NM 27 or 28!
3 -
3 hours ago, mina7601 said:
By the same logic, the question about the difference between Serpent 52 and Serpent 55 should be addressed in the FAQ, too.
Seriously though, easy, he's new to this forum, no need to go harsh. The user could have tried NM27 and NM28 by himself and know the differences, but he asked from early instead to know the differences.
Agreed. I wasn't casting aspersions on the user for asking - that was the right thing to do. Just pointing out that the question does come up a lot, and will probably continue to do so.
Rather than a long response, it would probably be easiest to beef up the FAQ with links to one of @VistaLover's detailed replies on those two topics.
46 minutes ago, j7n said:Why would you use New Moon 27 today?
I wouldn't use it, but it (and its sister K-Meleon) are more lightweight than current UXP browsers, so they might be reasonable "first browser" choices on older hardware where UXP is unacceptably slow. If it fails to render a site properly you could always fire up Serpent, go make a cup of coffee, drink it....
3 -
There's a thread on Supermium here at MSFN: https://msfn.org/board/topic/185045-supermium/
0 -
That question comes up so often, it probably should be addressed in the FAQ at the beginning of this thread.
2 -
On 3/29/2024 at 1:27 PM, Tester Machine said:
Links dead.
On 6/9/2023 at 3:15 AM, NotHereToPlayGames said:The user base for 360Chrome is far too small for me to consume that much storage space on my personal Dropbox account.
Agreed; it's your Dropbox account and you can put what you want there. But folks will keep finding this thread, and this will repeat, unless you at least remove the dead links from post 1. Also, if you follow the quote above back to the original post, you'll find a link to build 2036, whose links are also dead. Please don't frustrate new would-be users!
If it were me, I'd not only remove all those dead links, but also replace them with a link to the redux thread so folks can download the "newer, improved" version.
On 3/29/2024 at 1:53 PM, XPerceniol said:Are you going to continue to update at least the latest Redux?
Unfortunately I doubt there's much more that can done with 360EE. I'm just happy we have a reasonably modern (at least when beefed up with polyfills), lightweight, unGoogled Chromium for XP.
1 -
2 hours ago, j7n said:
It is obviously a result of one or a few sites storing oversized "cookies", possibly to sneak some advertising in. SQLite Manager lists 19801 entries inside the table webappstore2.
After an exercise of reading backwards, on the first page I recognize entries for hdtracks (possibly a culprit), softonic, pristineorganics, reddit, msfn, wikipedia, google, deezer (suspect), imgur (suspect), rateyourmusic, gtaforums, facebook. Looks like it may hold useful settings and logins that I need to keep, or I would need to log in to every place again, and likely don't remember the passwords.
Is this where the "Offline Web Content and User Data" shown when you go to Tools / Preferences / Advanced is stored?
I think logins and passwords are stored in a different table, but I'm not sure.
0 -
Wow - it's good to be back after that scary outage! Also good to see that nothing appears to have been lost.
On 3/9/2024 at 6:06 PM, Mathwiz said:Well, as usual, I was wrong - the first version of pdf.js that doesn't work (either regular or "legacy" version) is actually 2.16.105, the last published build of the V2 series, and by implication, the last version that does work is 2.15.349. So 2.15 appears to be the limit, at least without polyfills of some kind.
Mozilla appears to have updated their "legacy" translator between those two versions: the "legacy" version of 2.16.105 is smaller than the "legacy" version of 2.15.349, even though the regular version is slightly larger, which says to me that Mozilla removed some translations and/or polyfills from their legacy translator between those versions. This may account for 2.16.105 no longer working. Still, 2.15 is five years newer than 1.7 (July 31, 2022 vs. early 2017) and supports more of the functionality of Adobe Reader, albeit with a UI resembling Mozilla's post-Australis UI, Photon. Heck, even 2.5.207 (last version with the Australis-like UI) is three years newer (June 1, 2020). So we're overdue for an update.
It's been 2 1/2 weeks since I posted about pdf.js; unfortunately I was stopped by a problem I couldn't resolve and had to go back to the drawing board.
Although the pdf.js V2.15 I downloaded from GitHub works fine with some sites, it simply won't work with others. Problem is (or at least appears to be) that the downloaded version was intended to be hosted on a Web site, not run from within the browser (either built-in or as an extension). As a result, Serpent's cross-site scripting protection keeps kicking in if the site you're trying to download a .pdf from doesn't send the right "CORS" header saying it's OK for another "Web site" to access the pdf.
I couldn't figure out how to get around it, so I gave up on the GitHub versions. Instead I started extracting pdf.js from newer versions of Firefox. This worked better, without the XSS errors I was getting with the downloaded versions. I got up to FF 79, but that was still only at version 2.6.47. (Unfortunately Mozilla shuffled everything around in FF 80
and I haven't yet found the pdf.js in that or any newer version.)
So, a disappointing setback, and RL issues haven't helped. But I haven't given up yet.
0 -
On 3/14/2024 at 5:52 PM, reboot12 said:
I don't like to change the browser version often because sometimes something else works badly e.g. CPU Fan works longer or the browser closes at an unexpected moment without error.
Is this version Serpent 52 (2024-02-24) stable?
I hear you. But I still update more often than once every five months!
I believe the 2-24 Serpent versions are stable and that's what I'm running now. There have been no updates in several weeks, long enough to identify and fix any big issues.
1 -
On 3/16/2024 at 8:25 AM, reboot12 said:
I don't overwrite anything. I downloaded this:
https://o.rthost.win/palemoon/palemoon-27.10.0.win64-git-20240316-081721a2da-xpmod.7z
https://o.rthost.win/basilisk/basilisk52-g4.8.win64-git-20240224-3219d2d-uxp-b33b661414-xpmod.7zTest in VMware - fresh installed WinXP SP2 64-bit. Extract both files to C:\Program Files\palemoon and C:\Program Files\basilisk
Browsers have separate folders in %appdata%\Moonchild Productions
NM 27 and NM 28 typically use the same profile folder: %appdata%\Moonchild Productions\Pale Moon. If you wish to use both NM 27 and NM 28 on the same PC, you should make one or both portable to keep their profiles separate. (I believe a portable loader is mentioned in the first post of this thread.)
2 -
17 hours ago, VistaLover said:
... It's probably this one
:
https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/getTransform
Requires Fx70+
, Ch68+ ...
Found a polyfill for that and tried it. Unfortunately, I think my polyfill needs a polyfill of its own:
renderView: "TypeError: ctx.getTransform(...).invertSelf is not a function" viewer.js:9719:19
"invertSelf?" Good grief....
2 -
3 hours ago, VistaLover said:
I would argue they had blocked older clients for "security-related FUD"
That is certainly possible. I'm sure it was part of Chase's decision to require 109 (although only 106 on Android), since Chrome 109 was the oldest version to get the WebP fix last year.
But again, at least Chase can argue that they're trying to protect their customers' money; what's Science Direct trying to protect? As you noted, a Web server is at no risk from older browsers. But I bet a lot of Web developers don't understand that.
I think a lot of folks, even cybersecurity experts, don't really understand cybersecurity. They just know there are "vulnerabilities" and don't delve into what exactly is "vulnerable" and what isn't - so they just blindly try to close off every "vulnerability" they can get away with.
1 -
On 3/6/2024 at 4:15 PM, VistaLover said:
I'd have expected a "science-related" site to have implemented true scientific means (i.e. feature-detection) to check whether "my" browser is able to display it properly, but, hey, even "scientists" must have "sold their souls" to Google ...
Most likely, Science Direct didn't develop their Web site at all; they just hired some Web developer to do it, and the Web developer is still doing things the old way (UA sniffing). Chase.com is guilty of this too, but at least you don't expect better from bankers.
In (sort of) defense of UA sniffing, if the site wouldn't work, it's probably better to sniff the UA and give a message than to just have the Web site not work properly and frustrate the user. But in that case, they shouldn't require a newer version than what's actually needed for the site to work. Since the site apparently runs fine with Chromium 87, they don't need to be requiring (say) Chromium 109.
I suspect the developers tested with 109 (or whatever version), saw that it worked, and just blindly put in the version that they tested with as the requirement. Lazy, but who's going to complain (other than us)?
Anyway, thanks for the tip on a SSUAO extension for Chrome. I've been wanting one, but the user agent extensions I've seen recommended here haven't been site-specific.
1 -
1 hour ago, VistaLover said:
Erh
, you mean "previous" month ...
Yes, previous calendar month.
I suppose what I really meant was, "within the past 30 days or so...."
1 hour ago, VistaLover said:... please also try, if you will, 2.16-"legacy" on UXP (probably won't work there, too, but...)
Rats. 2.16 legacy didn't work on Serpent 52 either. Web console says something about "ctx.GetTransform is not a function."
'Twas worth a try, though....
2 -
Standard version of 2.14 works; legacy version of 2.15 works; neither version of 2.16 works. I actually haven't tried the standard version of 2.15 yet, so it's possible that it will work too - but as long as the legacy version works, I'm happy.
These experiments were actually with the Serpent 55 build from Feb. 8, 2024 (i.e., earlier this month); I haven't tried them with UXP (Serpent 52) but I expect that, if it works with 55, it works with 52 as well. Of course I'll confirm that before I publish anything.
1 -
On 3/7/2024 at 10:58 PM, Mathwiz said:
My guess is that 3.0 will be the first version that doesn't work - but they do have a "legacy" build of 3.0 that might.
Well, as usual, I was wrong - the first version of pdf.js that doesn't work (either regular or "legacy" version) is actually 2.16.105, the last published build of the V2 series, and by implication, the last version that does work is 2.15.349. So 2.15 appears to be the limit, at least without polyfills of some kind.
Mozilla appears to have updated their "legacy" translator between those two versions: the "legacy" version of 2.16.105 is smaller than the "legacy" version of 2.15.349, even though the regular version is slightly larger, which says to me that Mozilla removed some translations and/or polyfills from their legacy translator between those versions. This may account for 2.16.105 no longer working. Still, 2.15 is five years newer than 1.7 (July 31, 2022 vs. early 2017) and supports more of the functionality of Adobe Reader, albeit with a UI resembling Mozilla's post-Australis UI, Photon. Heck, even 2.5.207 (last version with the Australis-like UI) is three years newer (June 1, 2020). So we're overdue for an update.
1 -
I'm up to version 2.14.305 as of now. (The Photon-like UI works fine but looks a little "alien" to my eyes. If you're using a Photon theme, though, it may look like it fits right in.) My guess is that 3.0 will be the first version that doesn't work - but they do have a "legacy" build of 3.0 that might. I'll keep you posted.
Localization "should" work - the updated pdf.js looks for its localization files in ./web/locale and should ignore the built-in en-US locale (which I didn't bother to delete). But I haven't tested it.
Of course this is all with Serpent, which now supports newer JS constructs than the last XP-compatible Seamonkey version did. The extension developer may have stopped at 2.3.200 because that's all his SeaMonkey version could handle - or it could be that he just got tired of the project; I don't know.
That said, an extension is much simpler and easier to install than replacing the version built into omni.ja, so I may experiment with updating that extension, @AstroSkipper style
3 -
On 3/4/2024 at 7:38 AM, NotHereToPlayGames said:
There really is NO REASON to make an x64 version.
I tend to agree - but there's also no reason not to. The main reasons for making 64-bit versions of programs are to address large amounts of RAM in a single process, and to boost performance. Neither is as important for email clients as for browsers.
But @Jody Thornton wants one. I could see making it a low-priority project (not much demand), but unless there's something that just won't easily compile in 64-bit mode, I see no harm in giving it to him. The only downside is that the file would be slightly larger (and of course it would only run on 64-bit machines).
23 hours ago, Mathwiz said:What have I gotten myself into? Oh, well, I can always just give up....
I made a bit of progress on this last night. The "build" folder is a drop-in replacement. The "web" folder is almost a drop-in replacement, but you do have to make some changes to viewer.js and viewer.html. I got viewer.js figured out last night. I'll see if I can get viewer.html figured out tonight, then I'll see how new the version can get before the Javascript becomes hopelessly incompatible.
Edit: I got it sorted and am up to version 2.5.207 from June 1, 2020. This is the last version with the traditional UI; version 2.6 has a "Photon-like" UI. 2.5 has a couple more buttons but it looks and acts pretty much the same.
Version 1.7:
Version 2.5:
1 -
11 hours ago, VistaLover said:
I find some locale files are also relevant:
.\browser\!omni.ja\chrome\en-US\locale\pdfviewer\*
Well, as it turns out, there are some differences between the downloaded pdf.js releases, and the one built into omni.ja. Figures. (Couldn't make it simple, could you, Mozilla?)
In the downloaded releases, the locale files are in a "web" subfolder under the first path; not in a separate branch of the directory tree, as in the version built into omni.ja. I haven't yet determined whether the replaced l10n.js accesses the locale data from the new subfolder under "web"
Further testing will be needed to figure this thing out completely 
Edit: Still working on it, but I have figured out that the locale data built into omni.ja is US English only; the locale data in the standalone version is multilingual. So if I can figure this out, at least pdf.js will start working in other languages....
What have I gotten myself into? Oh, well, I can always just give up....
3 -
@anton12, your hostility mystifies me! (We are talking about Web browsers here. Unlike the canaries of the past, nobody dies. It's just a metaphor.)
Posting on this thread does not obligate anyone to be a beta tester for @roytam1's browser builds. Some have taken on this task, but voluntarily. I appreciate their efforts, but I see no reason why I should be expected to join them. I have my own interests, which I will pursue as I see fit.
As Billy Joel sang many years ago, "this is my life; go ahead with your own life, and leave me alone!" (Or - less politely - MYOFB.)
Now - on to a (hopefully) more interesting topic. On another thread, this was brought up:
On 2/26/2024 at 6:01 PM, VistaLover said:The [pdf.js] library inside the latest Serpent 52 build is of version "1.7.348-git-754c4bd", committed on 2017-03-04....
7 years ago seems pretty old to me! So I started wondering if newer versions would work. I found that pdf.js is contained in file omni.ja, so it's not super easy to replace the code, but it is possible. So as a test, I downloaded and extracted version 1.8.188, and replaced path chrome/pdfjs/content in omni.ja with that "newer" (by 1 month) code.
It seems to work, although I saw no obvious differences between 1.7.348 and 1.8.188. Still, the fact that it didn't just blow up in my face is encouraging. I plan to try progressively newer versions to see how far we can push pdf.js before being stopped by some JS feature not yet implemented in UXP. Stay tuned....
2 -
On 2/26/2024 at 10:29 AM, VistaLover said:
... "no sense" is probably only "applicable" to frequenters of these threads, on "legacy" browser engines
; I can assure you that the web designers of that Spanish site did NOT, even for a mere second, think of "backwards compatibility" 
; they're probably "trained" to expect each and every eventual user of their service to be running the latest Chrome/Firefox/Safari, where the original "issue" you reported (and generated many additional posts here) is simply non-existent....
It is undoubtedly true that those Web designers don't care one whit about compatibility with any browser other than the latest Chrome/Firefox/Safari! But that's not quite what I meant when I said it made "no sense" for a Web site to host pdf.js on their site.
What I meant was, they went to some extra trouble to do this, but got no apparent benefit from going to that trouble! It didn't make their .pdf pages readable on any of the "big three" browsers, since they all can display .pdf's without any help; it didn't speed up displaying of .pdf's; it broke any NPAPI plugins their Firefox users might be using (admittedly, the likelihood of them caring about that is only slightly higher than the likelihood of them caring about us Chromium 86 users); and it didn't save the site any bandwidth (to the contrary, it costs them additional bandwidth to download pdf.js to every site visitor who clicks one of their .pdf links)!
So why did they bother? The only reason I can think of is the same one you suggested:
On 2/26/2024 at 6:01 PM, VistaLover said:.. one "probable" answer why "enganchesaragon.com" choose to self-host an instance of the Mozilla PDF.js lib to display the PDF files "they" serve is: "They" prefer it over the native-PDF-viewer implementation on users' (mostly Chrome-based) browsers....
Firefox snobs? It sounds crazy, but as Sir Arthur Conan Doyle said through his fictional character Sherlock Holmes, "when you have eliminated the impossible, whatever remains, however improbable, must be the truth."
0 -
On 2/26/2024 at 10:45 AM, basilisk-dev said:
What's sad is that roytam1 continues to release code to his users that has not been verified as production ready. Code in the master branch of upstream UXP or upstream Basilisk is not always production ready. I have seen issues reported on MSFN for roytam1's builds because he was pulling code from master branches before they were ready. He is doing a disservice to his users by giving them potentially buggy code.
I don't know that it's necessarily "sad," but it is true. "Old-timers" on these threads are aware that these builds often include new features (and some old features - e10s) that aren't fully debugged. It's a double-edged sword; we're often the first to get fixes to longstanding bugs too (remember webp?), so there is an upside.
I think it's fine as long as you know what you're getting, but "newbies" who stumble onto these builds may not fully appreciate that, so they may run into problems on occasion. Luckily for them, this thread exists to help them out, and Roytam has always been quick to revert any changes that caused unforeseen problems.
Personally, I don't anxiously download every week's release. I let others be the canaries in the coal mine. And even then, I always keep my previous download as a backup, since things occasionally go sideways with new releases. I encourage others to do the same.
3 -
4 hours ago, NotHereToPlayGames said:
No worries here.
I have the 36-line version saved also (I have it labeled as [minor]).
I've never actually needed it but it *IS* a "confirmed fix" for a CHASE web site so I keep it just-in-case.
I don't have a CHASE account to know if the [major] version does or does not work on CHASE.
If it DOES, then I would throw away the [minor] and just resort to the [major].
But if the [minor] does have SOME web sites that it does work on, then until I can prove that it works where the [major] does not, then I keep both for just-in-case.
I tested [major]; it does not fix Chase. So keep [minor] around in case you run across other Web sites like Chase.
2
r3dfox, modern Firefox based web browser for Windows 7!
in Browsers working on Older NT-Family OSes
Posted
From the r3dfox readme: