Jump to content

My Browser Builds (Part 4)


Recommended Posts


1 minute ago, mina7601 said:

What's this

... Tab Mix Plus :P

Hmm..., if you had been closely following the discussions in this thread for the last 2 weeks, then you'd have remembered that tab-affecting extensions (notably TMP and TUP - Tab Utilities Phoenix) had been broken by a tab-related change that landed in previous Serpent 52 - start [re-]reading from here) ...

Greetings :)

Link to comment
Share on other sites

16 minutes ago, VistaLover said:

... Tab Mix Plus :P

Hmm..., if you had been closely following the discussions in this thread for the last 2 weeks, then you'd have remembered that tab-affecting extensions (notably TMP and TUP - Tab Utilities Phoenix) had been broken by a tab-related change that landed in previous Serpent 52 - start [re-]reading from here) ...

Greetings :)

Oh, sorry, I thought TMP was a short for temporary, since that's the meaning I see the most :P Anyway, thanks! :)

Link to comment
Share on other sites

18 minutes ago, VistaLover said:

... Tab Mix Plus :P

Hmm..., if you had been closely following the discussions in this thread for the last 2 weeks, then you'd have remembered that tab-affecting extensions (notably TMP and TUP - Tab Utilities Phoenix) had been broken by a tab-related change that landed in previous Serpent 52 - start [re-]reading from here) .

BTW, TUP's feature "multi-row tab bar" also works again in the latest releases of New Moon and Serpent:thumbup 

Link to comment
Share on other sites

@roytam1 Is it possible to display the "privacy" bar in K-Meleon 74/Goanna 2.2 on Windows XP (especially SP3)? I noticed on my Windows XP SP3 installation that it is not possible to display the "privacy" bar, but it is on Windows 2000. Copying macros.dll, privacy.dll, and toolbar.dll from the kplugins directory in K-Meleon 74/Gecko 24 to the kplugins directory in K-Meleon 74/Goanna 2.2 allows the "privacy" bar to display on Windows XP, but not on Windows 2000. 

K-Meleon 74/Goanna 2.2 on Windows XP:

305118688_2023-03-1118_42_52.jpg.36868d4de9802962390124aa0b58288e.jpg

K-Meleon 74/Goanna 2.2 on Windows 2000:

1780352145_2023-03-1118_44_46.jpg.8c9345c7651fe5cc79a83135c5fe05f8.jpg

Is it possible to fix that issue?

 

K-Meleon 74/Goanna 2.2 with the 3 mentioned kplugins on Windows XP:

561502624_2023-03-1118_43_34.jpg.ff0c37931a0e78357892b7f3e51faca4.jpg

Link to comment
Share on other sites

On 3/13/2023 at 12:17 AM, roytam1 said:
On 3/12/2023 at 5:47 PM, AstroSkipper said:

I just had a browser crash regarding mozglue.dll in the very latest release of New Moon 28 (28.10.6a1 (32-bit) (2023-03-10)). Here is the entry from the event log:

this is an old problem since feb uncovered by https://github.com/roytam1/UXP/commit/9824659d3c6b1c4fdc2616f789f0696d1cbe2ef8 and https://github.com/roytam1/UXP/commit/b7e4530861fcc971aee9d867b3b376e31263486c and they said it is fixed by https://github.com/roytam1/UXP/commit/1f0df8f421626bcbc397512773f3043d72d96a4f but I still need to revert first 2 mentioned commits in order to make it not crashing.

Thanks for the information! It would be great if reverting these commits really fixes these crashes. In the meanwhile, I had a further crash in mozglue.dll. :o

Link to comment
Share on other sites

25 minutes ago, AstroSkipper said:

Thanks for the information! It would be great if reverting these commits really fixes these crashes. In the meanwhile, I had a further crash in mozglue.dll. :o

you may revert to previous build or wait for next build

Link to comment
Share on other sites

18 hours ago, ClassicNick said:

Is it possible to display the "privacy" bar in K-Meleon 74/Goanna 2.2 on Windows XP (especially SP3)? I noticed on my Windows XP SP3 installation that it is not possible to display the "privacy" bar, but it is on Windows 2000.

Yes, something goes wrong on XP. After close of the first run K-Meleon 74 still runs in the background. Close this process k-meleon.exe with the Task Manager and on next start it should work as intended.

Link to comment
Share on other sites

Hi @UCyborg, somewhere in this thread (can't find it) you mentioned you delete most of the root files in basilisk (except xul) as the browser can find the included in root somewhere else in the system. Can you give more details on this?  Thanks!

Link to comment
Share on other sites

Hi all :P ...

Over the last 7 days or so, I have been browsing GitHub with the palefill extension disabled, thus making use of the recently corrected+improved native Web Components + Shadow Root support (i.e.
"dom.webcomponents.enabled;true"+"dom.getRootNode.enabled;true);
this is with previous Serpent v52.9.0 (2023-03-02) (32-bit), because with latest I get xul.dll crashes on GH 404 pages (see previous posts of mine).

With native WC I get overall better performance on GH compared to when using palefill (both the prefs I mentioned above should be toggled to false when using palefill, BTW), an added bonus is Turbo (aka "soft navigation") is now working on GH (palefill specifically disables it/is incompatible with it :() ...

But I've stumbled upon an irritating bug: GitHub timestamps :angry: ; when those are in the "minutes range" (e.g. 20 minutes ago), they pull a disappearing act :(...

Several minutes ago I loaded
https://github.com/roytam1/UXP/commits/custom

and took below screengrab:

O8RR81n.png

These timestamps are (or should be) dynamic, i.e. after 1 min has passed, their values should increase by 1 (so the one on latest commit should read "16 minutes ago"); give it a minute, boom, all timestamps vanish :angry:

G5159c9.png

To make the timestamps display in their updated state/values, you have to hard-refresh (CTRL+F5) the page (and even that occasionally fails) ...

The same thing happens with comment timestamps inside a GH issue tracker; I can't hard-refresh the page while in the middle of writing a comment myself, yet I still need to have a way to tell how back (in minutes) the recent comments above (the one I'm about to submit) were posted :D ...

Can someone with access to "upstream" (e.g. @UCyborg ;) ) relay this bug to them, so, perhaps, it could be investigated and, hopefully, remedied?

Many thanks :)

Edited by VistaLover
Link to comment
Share on other sites

17 minutes ago, VistaLover said:

These timestamps are (or should be) dynamic, i.e. after 1 min has passed, their values should increase by 1 (so the one on latest commit should read "16 minutes ago"); give it a minute, boom, all timestamps vanish :angry: :

Tried to check this in New Moon, but now the timestamp is 1 hour, so I' ll have to wait another hour to confirm this behaviour. :D

spacer.png

Link to comment
Share on other sites

59 minutes ago, nicolaasjan said:

so I' ll have to wait another hour to confirm this behaviour.

... The GH timestamps bug isn't limited to commits view/issue comments etc., and when "minutes" only; e.g. I just loaded

https://github.com/gorhill/uBlock/releases/tag/1.47.5b13

and tada :angry: :

n1nnaEy.png

... Reminds me of palefill issue no. 60 (different but related, sort of ;)):

https://github.com/martok/palefill/issues/60

:realmad: ...

Edited by VistaLover
Link to comment
Share on other sites

18 hours ago, VistaLover said:

With native WC I get overall better performance on GH compared to when using palefill (both the prefs I mentioned above should be toggled to false when using palefill, BTW)

Setting the preference dom.webcomponents.enabled to the value false in New Moon 28 is no option for me, unfortunately. nimportequoi.gif Due to a permanent 100% CPU utilization on VirusTotal ,for example, described in a previous post of mine. Therefore, this preference will stay here to the value true as long this abnormal behaviour exists, and presumably I'll just have to do without the GH timestamps in New Moon 28jexplique.gif 

Edited by AstroSkipper
Update of content
Link to comment
Share on other sites

16 hours ago, AstroSkipper said:
18 hours ago, VistaLover said:

With native WC I get overall better performance on GH compared to when using palefill (both the prefs I mentioned above should be toggled to false when using palefill, BTW)

Setting the preference dom.webcomponents.enabled to the value false in New Moon 28 is no option for me, unfortunately. nimportequoi.gifDue to a permanent 100% CPU utilization on VirusTotal, for example, described in a previous post of mine. Therefore, this preference will stay here to the value true as long this abnormal behaviour exists, and presumably I'll just have to do without the GH timestamps in New Moon 28jexplique.gif

Ok. I tested this GH timestamps behaviour a bit more deeply. It looks like I won't have to give up the GH timestamps after all. I've been using the extension Lull The Tabs for a long time in all my UXP browsers. This extension seems to interfere on GitHub sites which results in lacking of GH timestamps. Only disabling this extension or excluding the website GitHub.com in Lull The Tabs'options solves the problem. Edit: But only temporarily. There are more problems in my main profile. I need to investigate this strange behaviour much deeper. uniforme4.gif

Edited by AstroSkipper
Update of content
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...