Jump to content

Mathwiz

Member
 View Profile  See their activity

  • Posts

    1,862

  • Joined

  • Last visited

  • Days Won

    51

  • Donations

    0.00 USD 

  • Country

    United States

 Content Type 

Everything posted by Mathwiz

  1. Mathwiz
    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.
  2. Mathwiz
    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.
  3. Mathwiz
    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
  4. Mathwiz
    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). 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:
  5. Mathwiz
    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....
  6. Mathwiz
    @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: 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....
  7. Mathwiz
    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: 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."
  8. Mathwiz
    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.
  9. Mathwiz
    I tested [major]; it does not fix Chase. So keep [minor] around in case you run across other Web sites like Chase.
  10. Mathwiz
    <OT>Yes; St 55 does the same thing. And, I saw no errors in the Error Console! So no clue what missing functionality is needed to get that thing working in St. Maybe MCP's StructuredClone implementation has let me down again. I'll try @UCyborg's 250-line polyfill and see if that fixes it. Edit: No luck, so it must be something else, since we know @UCyborg's version (actually ungap's version) does fix it in Chrome. So presumably St (52/55) use an older version of the same thing, since they were forked from Firefox.</OT> But I still can't understand why one would host pdf.js on a Web page, since Firefox and Chromium already have the needed functionality built in.
  11. Mathwiz
    Here's the one @UCyborg posted about a month ago: https://msfn.org/board/topic/185918-arcticfoxienotheretoplaygames-360chrome-v1351030-redux/?do=findComment&comment=1258371 Edit: NHTPG posted one above, but it's an image. Follow my link if you want a cut-and-paste version.
  12. Mathwiz
    I'm kind of astonished by the design of this Web site. Am I correct in concluding that, rather than using the .pdf viewer built into every major Web browser, they coded their own? In Javascript? Why would anyone do this? It can't have been done to support very old browsers that might lack a built-in .pdf viewer, because the Javascript relies on new constructs that require polyfills even on Chrome 86. Older browsers don't stand a chance. P.S.: Per Google Translate, that line in German above translates to "An error occurred when loading the PDF file." So I'd guess that this Javascript PDF viewer was written by a German. (I realize that doesn't tell us much.) P.P.S.: Maybe the German thing is a red herring. I just tried to open the .pdf in Acrobat 9 and was told that I need a newer Acrobat version! So perhaps, to answer my original question, the .pdf is a very new format, and the Javascript .pdf viewer actually does allow (slightly) older browsers to view the .pdf. Like Chrome 98 or so. Except - that doesn't make sense; @VistaLover was able to view it with the .pdf viewer built into Kafan MiniBrowser (Chromium 87). So I guess I still don't understand the purpose of this thing.
  13. Mathwiz
    Do those refer to the dom.dialog_element.enabled pref? I've had that manually enabled for years, I think. No ill effects that I know of.
  14. Mathwiz
    Yes it is. The final ESU update (only for Win 7 Embedded, and whatever the server edition was that went with Win 7) dropped last month, so even if you paid for that, you are now at EOS. <OT>The last official Chrome/Edge versions for Win 7 are 109. (Luckily Chromium fans have @win32's Supermium.) Firefox ESR 115 isn't quite at EOS yet but it's getting close! (Will there be a Superfox?)</OT> I'm less sure about Australis-based Firefox forks, but I think the most advanced one Win 7 has is either Waterfox Classic or Basilisk/Serpent. Waterfox Classic hasn't been updated in over a year though, so it still has some security vulnerabilities (the WebP vulnerability, for example).
  15. Mathwiz
    New Moon 27 was forked from a much older Firefox version that uses a different engine than either Serpent version. So NM 27 updates are generally not applicable to Serpent. New Moon 28 and Serpent 52 use the same engine (UXP - forked from FF ESR 52.6, IIRC), and Serpent 55 (forked from an alpha version of FF 53) is similar. So those three often get updated at the same time.
  16. Mathwiz
    Apparently @D.Draker doesn't understand the concept of hyperbole. Of course it was an extreme exaggeration; I had hoped that was obvious to everyone, but apparently not. But he did leave me wondering: what exactly is an "over-exaggeration?" Is there such a thing as an "under-exaggeration?" If I had said 16 MB and an 8-core processor, would he have accused me of under-exaggerating because I only exaggerated a little? And what level of exaggeration is "just right?" Is 32 MB the "Goldilocks" level of exaggeration in D.Draker's opinion? (BTW, even 8GB and a quad-core processor is rather beyond the hardware used by the typical XP user.)
  17. Mathwiz
    For those who don't want to read through a long thread, I offer the following pull-quote from MC: I tend to agree, both with MC's take (bad website design) and @VistaLover's pessimism that anything will change. "It runs just fine on the latest Chrome and even Firefox, with only 64GB RAM and five dozen processor cores! What - you don't throw out and replace your PC every month? You aren't running Win 11? What's wrong with you?"
  18. Mathwiz
    That might have been a version of a problem I (and many others, I assume) have run into at one time or another: if you don't have an ad blocker, and the site hosting your desired ad blocker is itself cluttered with ads, it can be quite challenging to find the "real" download link among all the "fake" download links from ads designed to look like the site itself! Free download sites like Mediafire have to run ads to stay in business; unfortunately they aren't always very selective about the ads they run. Luckily this is usually a problem only when you first start using a new browser. Once you do manage to get that first ad blocker installed, everything is fine.
  19. Mathwiz
    Well, after I replaced uBO 1.16.4.31b2-1.54.0 with the newly released uBO 1.16.4.31 in Serpent 55, something went seriously haywire overnight! Yesterday, all was well, but today, things weren't working right. Some sites were hanging on load, and some annoyances (cookie notices, etc.) that had been filtered out for ages suddenly reappeared. Turned out Serpent 55 had updated uBO to version 1.17.4 overnight! Apparently, returning to a "sane" version number allowed Serpent 55 to find a "newer" version at AMO. 1.17.4 is a WebExtensions version, but it does run in Serpent 55. However, it's much, much older and lacks many of the filter lists @AstroSkipper had added. Had to uninstall uBO, reinstall @AstroSkipper's version, reload my settings from backup, and turn off auto-updating of uBO in the browser's Extensions page. Things seem to be back to normal again, but that was a huge mess. Hopefully there won't be any more unpleasant surprises!
  20. Mathwiz
    Yes, such a cash-strapped company; gotta pinch every penny!
  21. Mathwiz
    I know this is a Windows forum, but that's something I didn't know about! The iOS/Safari version of uBO limits the number of filters in a list? I'm sure there's a reason....
  22. Mathwiz
    Wow - I didn't expect even one reply to my puzzlement about the standard search icon having become the magnifying glass, let alone two! But yes, I am quite familiar with the image of Sherlock Holmes searching for clues with a magnifying glass. It's become (ahem) iconic. And yes, I'm sure that image is why a magnifying glass has become the standard icon for "search." But detective work is rather unique: you generally know where to search (the crime scene); it's just that many important clues are tiny, hence the need for a magnifying glass. For more mundane searches, though, such as searching for misplaced car keys, a magnifying glass is pretty useless. So when I see a magnifying glass, my first thought isn't of Sherlock Holmes searching for clues; it's of (duh) magnification! As @Ascii2 said, Which I think is the mistake filterlists.com made: you don't know their magnifying glasses mean "search" until after you click them!
  23. Mathwiz
    For better or worse, the magnifying glass and funnel have become de facto standard icons for "Search" and "Filter/Select," respectively, both on Web sites and standalone software. I always found the magnifying glass a bit puzzling. When I search for something, I certainly don't use a magnifying glass! I think this came from an old Windows animation that showed a magnifying glass being moved around when Windows was searching for a file, but that animation never made much sense to me either. Methinks a magnifying glass would be a better icon for "Details" or "Enlarge" than for "Search." To me, a flashlight/torch would've made more sense as a "Search" icon. (There's even a different old Windows search animation that shows a flashlight being moved back and forth.) But, I understand it's hard to come up with a good icon. The funnel makes more sense to me than the magnifying glass, although to be nitpicky, a filter is placed in a funnel - it's not the funnel itself! Still, I can at least understand the connection. My biggest problem with the funnel icon was that it wasn't immediately obvious what the icon is! It looked to me more like an upper-case Y! It took me some time to realize that it was intended to be a funnel.
  24. Mathwiz
    From the discussion @VistaLover linked to above: It puzzled me too. It sounds to me like the CSS was written to work even if aspect-ratio: 1 isn't supported; yet the browser compatibility testing script (at least they did it with feature detection vs. UA sniffing) insists on such support anyway. Sounds to me like the CSS and JS developers weren't communicating with each other. At a minimum, the script should provide the "modern" Web site if that's the only feature the browser lacks, perhaps with a "We'll stop supporting this browser soon" banner (with a clickable X to remove it) if there are plans to "upgrade" the CSS to require that support in the future.
  25. Mathwiz
    Yes, and it happened again to @DanR20! What I'm saying, though, is that if any extension crashes the browser, that has to be the browser's fault! Unlike Flash and other plug-ins, extensions don't have their own machine code. (Well, a tiny few do, but those "helpers" have to be downloaded and installed separately from the extension itself, so at least you're aware of them.) Extensions are just CSS, JavaScript, HTML, etc., and it's the browser's job to read and interpret those things, and handle any errors therein. Of course, as a practical matter, if an extension is crashing your browser, the best course of action may well be to remove and replace the extension, rather than waiting for the browser developer to fix the crash. After all, even if the crash is fixed, the extension still may not work properly. We're lucky (and a bit spoiled) to have @roytam1 able to deal with issues like this so quickly.
×
×
  • Create New...