RamonUn

Thanks a lot roy, for the Optional Chaining I am already using this trick and it works fine.

To auto-detect queueMicrotask , I used the following code in the palefill code: this.hasqueueMicrotask = typeof queueMicrotask === 'function'; https://github.com/RamonUnch/palefill/commit/32c411ded85804ea9bb1dcbaf121fda9321dec2d#diff-7934bf411fea192ad8cd69e0a12911648a2842cb0f2409a8fb67b41b7069d757R558 However, even with the latest New Moon build I get the 'false' result. I think I am doing something wrong but when I tried this code in the try javascript web application, I get true. Is there any way to detect the availability of queueMicrotask without having to create a Worker object and without relying on versioning. Sorry if my question is dumb but I have zero knowledge in JavaScript.

I was planning to disablle version checking, I instead auto-detect features: https://github.com/RamonUnch/palefill/pull/2/files

I had the same problem, took me a while to figure it out.

It has better ePub compatibility and more importantly for me, the ability to setup shortcuts with better shortcuts for annotations. I can live with version 3.3.3 for the near future, but in the long run, I like the Idea to also have a more up-to date mupdf engine that will be more compatible with all random PDFs that I could come across. In the End the release cycle of SumatraPDF seems to be one version a year which is still very reasonable.

Seems to be possible indeed: https://stackoverflow.com/questions/23147087/how-to-detect-syntactical-features-of-javascript In general it seems useless but in this case this is the way to go. It would be the most practical thing indeed, I Just need too learn JavaScript at some point. However for the UXP platform there are very few builds anyway so a version based system should be fine.

I did not update version number on purpose, that is strange. Must have been bumped in the base repo. Edit: Indeed it was bumped up Just before I forked, fixed now.

I made a fork of palefill to get a more forgiving install.rdf. so that it can be installed on NewMoon28, Serpent, IceApe-UXP and BNavigator https://github.com/RamonUnch/palefill/releases Also you I check for UXP version 4.8.5 and later to know if some polyfill should be disabled

Ok, I understand. Just to be sure then, In term of polyfill is there any difference? UXP-5.1.0 supports: std-queueMicrotask, dhl-optchain and tmx-optchain. From what I tested it seems 4.8.5 is good on those polyfill as well, and I think I can give the link to a modified palefill-1.11.xpi that supports NewMoon28, Serpent59, IceApe-UXP and BNavigator without overloading those on UXP-4.8.5+ here for people that are interested: https://github.com/RamonUnch/palefill/releases

@roytam1 Why are you not updating version number in your custom builds? Your UXP version in term of features is like version 5.1.0. The latest Serpent build is close to equivalent to the latest Basilisk in term of feature support. A Plugin like palefilll uses the UXP version number to check features availability and apply fixes accordingly: Commit (from yesterday): https://github.com/martok/palefill/commit/faf9a9267871b56c366eee5e7ce2ecb85541bca5 Also because of the minimum version requirements you need to manually edit the install.rdf file even for PM28 that is officially supported but version number increments slower on your builds so we are still to PM28.10.x even though it is closer to PM31 in term of web support. There is probably a good reason for your version numbering system but I do not understand it. I could make a fork of the palefill plugin to better support your UXP based browsers but I actually never wrote any plugins. EDIT: actually modifying the plugin is trivial matter, I, just need to change 5.1.0 into 4.8.5 I will try that.

Windows XP misses the GetTickCount64 function but if you just hexedit it to GetTickCount then the program seems to work just fine on XP. Tested with furnace version 0.5.8 (win32)

Note that now the fix was included into palefill 1.11 and does not interfere with any global setting: https://github.com/martok/palefill also fixes bunch of other websites on palemoon.

@user57 A new SumatraPDF version was just released. (version 3.4.1) It contains some nice new features. I hope you will consider making a build. Maybe wait a couple weeks before doing so so that you are sure 3.4.x branch got stable.

I just saw the new Mypal beta release, based on Firefox 68 and I can say I am impressed on how smooth it is on my machine. Certainly there is a huge potential in this project. @feodor2 is a genius. I am writing those lines from Mypal 68.

I forgot to check the configure options, I can see them now in about:buildconfig. Thanks for the clarification! Any reason you disable them on NewMoon? I do not think it would impact performances, would it? I do not have a build environment so I cannot check, nor test some fixes for the bad caret tracking even when accessibility is enabled.

There is an issue with accessibility option for New Moon related to the caret position. I realized this while developing an "extended key menu" to be able to type easily accentuated characters with any keyboard layout. For this I need to popup a menu at the caret position, however the focused program needs to have a native windows caret in order for this to be possible (using GetGUIThreadInfo()), and it is not the case with all of yours browsers. The same problem applies to the Windows Magnifier that centers on the caret position as soon as you type in something, also using GetGUIThreadInfo() function (I think). A native Windows caret is created according to the UXP source as soon as accessibility option is activated, This is needed for the magnifier, so it works mostly fine on IceApe-UXP as well as on Serpent. There are some bugs here and there but I will talk more about them later. There are also Other calls to ::SetCaretPos() in "widget/windows/IMMHandler.cpp" and in "widget/windows/TSFTextStore.cpp". The biggest Issue is with PaleMoon28, for some reasons the Magnifier is unable to track the caret position. I assume it ends up not being created. Could this be fixed? I tested a few of your builds: 1) IceApe-UXP: OK 2) bnavigator: OK 3) Serpent: OK 4) KM-Goanna: OK 5) MailNews: OK I did not test other browsers, so for Me only NewMoon seems to have the problem. There are a few bugs when using the magnifier even with those working browsers: 1) it seems that a wrong value of Caret position is given when you navigate through text with left/right arrows, or when you press origin/end keys. It also seems it is updated only every few lines when using the up/down arrow lines. 2) it also seems that the caret position is updated only when at the end of a line and when typing a character. This has the advantage of making the text less moving in the magnified window but it also means that you often are unable to see what you type in the Magnifier. Do you have any clue why Magnifier completely fails to track the caret on NewMoon? could be this fixed? I think this is a bit problematic because I do know a couple of guys that need the Magnifier. PS: I tried RetroZilla and here everything is perfectly flawless in this regard!

It seems the profile directory went back to "%APPDATA%\Binary Outcast\Interlink" is this desired? Before I had the build "mailnews.win32-20210821-355db4de-uxp-4ac28d1d4-xpmod.7z" and it was saving profile to "%APPDATA%\OpenSource\MailNews"

I got the same problem for the same reason, I also donated $20 and realized afterward that I had donated as anonymous. The important is that the money comes to msfn. Thanks for your clarification.

I do use server2003 and it does work 2003 is almost the same as XP. For me CTRL+Click in the taskbar has always be a nice feature, I do not understand why they removed it, it is really annoying.

Your DLL works probably perfectly fine on XP, missing dynamic import are non problematic because none of them are made by jxl.dll, I just think iview needs his functions to be defined, the dll, this is why those extra functions are exported by the iview's jpeg_xl.dll. If we had access to the documentation of plugin interface of iview, it would not be difficult, I think to implement those functions. I looked for such doc/sdk but could not find it, I guess iview developer does not want random people to make plugins.

Thanks for your work, I started trying to make a build with cmake+mingw but I got problems with missing unix timing functions and I stopped. On my windows server2003 with your plugin, I still see the same error on loading an jpx file, however I see the dll on the plugin list (without version number because you of missing GetPlugInInfo I guess). The dependency log is attached as rtf file (so you get colors). GetPlugInInfo is used at least for version information, but I suspect it also returns a structure, pointing to a list of functions. that contains the function name to be used for encoding/decoding. In the original I got: ReadAnimatedJXL_W ReadJXL_W SaveJXL_W ScanJXL_W ShowPlugInOptions_W ShowPlugInSaveOptions_W GetPlugInInfo Those are iview only functions that are probably listed when you call GetPluginInfo. this is why (I guess), at the end of the log iview is trying to get an empty proc address. in JPE You would need to re-implement some of those functions but I do not know their prototype. probably iview forum may help you. Loading JPpeg_XL.rtf

Do not worry, my windows is not cluttered, I have a very good control of exactly what is running on my machine, Even when I had to use Win10, after a few weeks of work I was able to make it run smoothly without a SSD, and had less than 50 running services. Also my computer is quite clean and I tried from two different computers. The problem probably comes from the speed of my internet connection that rarely goes above 30KB/s on good days, today is mostly 10KB/s, or maybe my internet provider is playing me tricks.

@NotHereToPlayGames I am unable to download your ungoogled 13.5 builds: https://www.dropbox.com/s/myo8zicm9af8qgy/360ChromePortable_13.5.1030_rebuild_5_ungoogled.zip The download just starts fine and then gets stuck a few percents before the end. I tried with 3 different browsers at different moments and I still cannot download it fully. Could you provide an alternative location? or maybe try to re-upload it? Thanks for your good work!

@roytam1 I made a fork of your GreenPad's version, the source is here: https://github.com/RamonUnch/GreenPad No Win32s version yet though (I have no Win32s environment yet). Also, thanks a lot for your browsers builds, I use them all the time (for now IceApe-UPX is my main browser, but I do use others too).

I completely agree that a DLL like this should have almost no dependencies because it is here just to decode, and I am sure that with the source it would not be so hard to make it compatible even with NT3.x/Win9x. An idea could be to write the jpeg-xl plugin yourself given that the reference encoder/decoder is opensource: https://github.com/libjxl/libjxl/ Not sure where to get the doc to make a plugin. Also it seems that the provided builds are *almost* XP compatible, so you can use cjxl.exe and djxl.exe command line programs just by changing the required OS value in the PE header (using a hex editor). Actually not exactly I get a crash when trying to decode the IMG_20200308_194050.jxl example file. I am sure that if you build it yourself, with a bit of tuneup, you will be able to get them working.