Jump to content

My Browser Builds (Part 4)

roytam1
 Share

Recommended Posts

Mark-XP

Mark-XP

Posted
Posted
9 hours ago, Mathwiz said:

I especially like the error messages that just say Error: :rolleyes: Big help.

"define is not defined" isn't bad as well: a very interesting proposition from a linguistic-logical perspective :).

3
Link to comment
Share on other sites

AstroSkipper

AstroSkipper

Posted
Posted (edited)
3 hours ago, Mark-XP said:

"define is not defined" isn't bad as well: a very interesting proposition from a linguistic-logical perspective :).

Linguistically a little curious, but if the function "define" is simply not defined, it still makes sense. ;)

Edited by AstroSkipper
4
Link to comment
Share on other sites
VistaLover

VistaLover

Posted
Posted
2 hours ago, UCyborg said:

Public class fields

Thanks for your investigation :thumbup ;

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Public_class_fields#browser_compatibility

says that this JS syntax feature has been implemented in Chr72+/Fx69+ (so, a long time ago :o); "upstream" now have an open UXP issue about it, opened just 2 months ago by @martok (the maintainer of palefill):

https://repo.palemoon.org/MoonchildProductions/UXP/issues/2142

This is being worked on currently, so, fingers crossed, "we" may see a positive outcome/resolution soon-ish ;) ...

Slightly OT: I was puzzled by the fact my 360EEv11 copy, Chr69-based, was able to display images inside

https://www.winhelponline.com/blog/disable-full-row-select-explorer-windows-7/

since the "feature" was only implemented as of Chr72, but then I realised I had, since long ago, enabled the "Experimental JavaScript" flag in that build :thumbup (chrome://flags/#enable-javascript-harmony); mystery solved, as that flag enables a "draft" version of public class fields already in Chr69!

1
Link to comment
Share on other sites
Proteus

Proteus

Posted
Posted

I have stumbled on an annoying glitch in 64 bit New Moon v28 in XP64. When opening the Synology Diskstation NAS page and dropping any file from the Explorer into its window New Moon triggers a response: "You have chose to open....download etc" dialog as if there is just a normal htm page in the backgound.

Under New Moon 32-bit or 64-bit Basilisk 55 Diskstation's window (with underlaying DSM software) just accepts a file. None of the previous year 64-bit New Moon worked OK (always using fresh profile). Or am I missing something?

Link to comment
Share on other sites
Saphir

Saphir

Posted
Posted (edited)

Good news as it seems, Martok is trying to getting rid of 2 UXP villains:
https://repo.palemoon.org/MoonchildProductions/UXP/issues/2142
and
https://repo.palemoon.org/MoonchildProductions/UXP/issues/2097

See here for progress
https://repo.palemoon.org/martok/UXP-contrib/commits/branch/work/class-fields

And also with Dynamic Module Import worked on, it seems that if everything turns out as planned, UXP based browsers will soon receive a very high compatibility boost necessary for the modern web :)

Edited by Saphir
1
Link to comment
Share on other sites
mina7601

mina7601

Posted
Posted (edited)
3 minutes ago, Saphir said:

Good news as it seems, Martok is trying to getting rid of 2 UXP villains:
https://repo.palemoon.org/MoonchildProductions/UXP/issues/2142
and
https://repo.palemoon.org/MoonchildProductions/UXP/issues/2097

The first and second link open the same page, though the second link opens a different page if you copy-paste it.

Edited by mina7601
Link to comment
Share on other sites
roytam1

roytam1

Posted
  • Author
Posted (edited)
On 4/27/2023 at 7:55 AM, Saphir said:

Good news as it seems, Martok is trying to getting rid of 2 UXP villains:
https://repo.palemoon.org/MoonchildProductions/UXP/issues/2142
and
https://repo.palemoon.org/MoonchildProductions/UXP/issues/2097

See here for progress
https://repo.palemoon.org/martok/UXP-contrib/commits/branch/work/class-fields

And also with Dynamic Module Import worked on, it seems that if everything turns out as planned, UXP based browsers will soon receive a very high compatibility boost necessary for the modern web :)

dbsoft created PR for dynamic import as well.

But I don't think they will merge "in-time" for my weekly build, so there could be no UXP based builds this week.

Edited by roytam1
1
Link to comment
Share on other sites
roytam1

roytam1

Posted
  • Author
Posted

New NewMoon 27 Build!

32bit https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20230429-a8e11fd667-xpmod.7z
32bit SSE https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20230429-a8e11fd667-xpmod-sse.7z
32bit noSSE https://o.rthost.win/palemoon/palemoon-27.10.0.win32-git-20230429-a8e11fd667-xpmod-ia32.7z

64bit https://o.rthost.win/palemoon/palemoon-27.10.0.win64-git-20230429-a8e11fd667-xpmod.7z

source repo: https://github.com/roytam1/palemoon27

repo changes since my last build:
- import changes from `dev' branch of rmottola/Arctic-Fox:
 - Bug 1187146 - Replace nsBaseHashtable::Enumerate() calls in js/xpconnect/ with iterators. r=mrbkap. (28d2b6078d)
 - Bug 1226119 - Clear pending exception from script cache writing failure. r=bholley (cca6220b3e)
 - Bug 1218029 - Adds IncrementalStreamLoader interface stubs. r=djvj (d2eaf684d5)
 - Bug 1218029 - Adds ScriptLoadHandler and implements OnIncrementalData callback. r=djvj (8f841b143d)
 - Bug 1228467 - Don't preprocess dom/base/UseCounters.conf. r=froydnj (534610a94c)
 - add EME bits to keep PP happy (47840e6c56) (0394c7f1d2)
- import changes from tenfourfox:
 - #651: M1779993 + backbugs (9197c1505)
 - #651: M1786188 M1791029 (28b4c0882)
 - #651: M1761233 M1687303 M1633019 M1797336 M1799748 M1801102 (fb91afbb4) (8e435782a0)
- import changes from `dev' branch of rmottola/Arctic-Fox: Bug 821291 - Move libmozgnome into libxul. r=glandium,karlt (83f14b4257) (a8e11fd667)

Link to comment
Share on other sites
roytam1

roytam1

Posted
  • Author
Posted

New regular/weekly KM-Goanna release:
https://o.rthost.win/kmeleon/KM76.4.7-Goanna-20230429.7z

Changelog:

Out-of-tree changes:
* update Goanna3 to git 5602866910...a8e11fd667:
- import changes from `dev' branch of rmottola/Arctic-Fox:
 - Bug 1187146 - Replace nsBaseHashtable::Enumerate() calls in js/xpconnect/ with iterators. r=mrbkap. (28d2b6078d)
 - Bug 1226119 - Clear pending exception from script cache writing failure. r=bholley (cca6220b3e)
 - Bug 1218029 - Adds IncrementalStreamLoader interface stubs. r=djvj (d2eaf684d5)
 - Bug 1218029 - Adds ScriptLoadHandler and implements OnIncrementalData callback. r=djvj (8f841b143d)
 - Bug 1228467 - Don't preprocess dom/base/UseCounters.conf. r=froydnj (534610a94c)
 - add EME bits to keep PP happy (47840e6c56) (0394c7f1d2)
- import changes from tenfourfox:
 - #651: M1779993 + backbugs (9197c1505)
 - #651: M1786188 M1791029 (28b4c0882)
 - #651: M1761233 M1687303 M1633019 M1797336 M1799748 M1801102 (fb91afbb4) (8e435782a0)
- import changes from `dev' branch of rmottola/Arctic-Fox: Bug 821291 - Move libmozgnome into libxul. r=glandium,karlt (83f14b4257) (a8e11fd667)

* Notice: the changelog above may not always applicable to XULRunner code which K-Meleon uses.

A goanna3 source tree that has kmeleon adaption patch applied is available here: https://github.com/roytam1/palemoon27/tree/kmeleon76

Link to comment
Share on other sites
roytam1

roytam1

Posted
  • Author
Posted
On 4/22/2023 at 7:29 AM, roytam1 said:

and got another GC related crash on 64bit as well: 

Unhandled exception at 0x000007FEDE2F31B8 (mozjs.dll) in palemoon.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

>	mozjs.dll!DispatchToTracer<JSObject * __ptr64>(JSTracer * trc, JSObject * * thingp, const char * name) Line 680	C++
 	mozjs.dll!DoMarking<js::RegExpShared>(js::GCMarker * gcmarker, js::RegExpShared * thing) Line 806	C++
 	mozjs.dll!CallTraceHook<TraverseObjectFunctor,js::GCMarker * __ptr64 const,JSObject * __ptr64 & __ptr64>(TraverseObjectFunctor f, JSTracer * trc, JSObject * obj, CheckGeneration check, js::GCMarker * const && <args_0>, JSObject * & <args_1>) Line 1515	C++
 	mozjs.dll!js::GCMarker::processMarkStackTop(js::SliceBudget & budget) Line 1727	C++
 	mozjs.dll!js::GCMarker::drainMarkStack(js::SliceBudget & budget) Line 1560	C++
 	mozjs.dll!js::gc::GCRuntime::markGrayReferences<js::gc::GCZoneGroupIter,js::CompartmentsIterT<js::gc::GCZoneGroupIter> >(js::gcstats::Phase phase) Line 3847	C++
 	mozjs.dll!js::gc::GCRuntime::endMarkingZoneGroup() Line 4331	C++
 	mozjs.dll!js::gc::GCRuntime::sweepPhase(js::SliceBudget & sliceBudget, js::AutoLockForExclusiveAccess & lock) Line 4918	C++
 	mozjs.dll!js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget & budget, JS::gcreason::Reason reason, js::AutoLockForExclusiveAccess & lock) Line 5384	C++
 	mozjs.dll!js::gc::GCRuntime::gcCycle(bool nonincrementalByAPI, js::SliceBudget & budget, JS::gcreason::Reason reason) Line 5666	C++
 	mozjs.dll!js::gc::GCRuntime::collect(bool nonincrementalByAPI, js::SliceBudget budget, JS::gcreason::Reason reason) Line 5779	C++
 	mozjs.dll!js::gc::GCRuntime::gcSlice(JS::gcreason::Reason reason, __int64 millis) Line 5854	C++
 	mozjs.dll!js::gc::GCRuntime::gcIfRequested() Line 6033	C++
 	mozjs.dll!js::gc::GCRuntime::gcIfNeededPerAllocation(JSContext * cx) Line 237	C++
 	mozjs.dll!js::Allocate<JSObject,1>(js::ExclusiveContext * cx, js::gc::AllocKind kind, unsigned __int64 nDynamicSlots, js::gc::InitialHeap heap, const js::Class * clasp) Line 50	C++
 	mozjs.dll!JSObject::create(js::ExclusiveContext * cx, js::gc::AllocKind kind, js::gc::InitialHeap heap, JS::Handle<js::Shape *> shape, JS::Handle<js::ObjectGroup *> group) Line 376	C++
 	mozjs.dll!js::LexicalEnvironmentObject::createTemplateObject(JSContext * cx, JS::Handle<js::Shape *> shape, JS::Handle<JSObject *> enclosing, js::gc::InitialHeap heap) Line 845	C++
 	mozjs.dll!js::LexicalEnvironmentObject::createTemplateObject(JSContext * cx, JS::Handle<js::LexicalScope *> scope, JS::Handle<JSObject *> enclosing, js::gc::InitialHeap heap) Line 868	C++
 	mozjs.dll!js::LexicalEnvironmentObject::clone(JSContext * cx, JS::Handle<js::LexicalEnvironmentObject *> env) Line 969	C++
 	mozjs.dll!js::jit::BaselineFrame::freshenLexicalEnvironment(JSContext * cx) Line 69	C++
 	[External Code]

 

yet another crash: 

Unhandled exception at 0x000007FEDE1563A0 (mozjs.dll) in palemoon.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

Source(Marking.cpp):
template <>
bool
MustSkipMarking<JSObject*>(GCMarker* gcmarker, JSObject* obj)
{
    // Don't trace things that are owned by another runtime.
    if (IsOwnedByOtherRuntime(gcmarker->runtime(), obj))
        return true;

    // We may mark a Nursery thing outside the context of the
    // MinorCollectionTracer because of a pre-barrier. The pre-barrier is not
    // needed in this case because we perform a minor collection before each
    // incremental slice.
    if (IsInsideNursery(obj))
        return true;

    // Don't mark things outside a zone if we are in a per-zone GC. It is
    // faster to check our own arena, which we can do since we know that
    // the object is tenured.
    return !TenuredCell::fromPointer(obj)->zone()->isGCMarking(); // <-- crash here
}

Local Variables:
+		gcmarker	0x0000000005e6ebd0 {stack={stack_=0x0000000067b02000 {133648452} tos_=0x0000000067b054e0 {2128553144} ...} ...}	js::GCMarker *
		obj	Variable is optimized away and not available.	

Stack:
>	mozjs.dll!MustSkipMarking<JSObject * __ptr64>(js::GCMarker * gcmarker, JSObject * obj) Line 790	C++
 	mozjs.dll!DispatchToTracer<JSObject * __ptr64>(JSTracer * trc, JSObject * * thingp, const char * name) Line 680	C++
 	mozjs.dll!DoMarking<js::RegExpShared>(js::GCMarker * gcmarker, js::RegExpShared * thing) Line 806	C++
 	mozjs.dll!CallTraceHook<TraverseObjectFunctor,js::GCMarker * __ptr64 const,JSObject * __ptr64 & __ptr64>(TraverseObjectFunctor f, JSTracer * trc, JSObject * obj, CheckGeneration check, js::GCMarker * const && <args_0>, JSObject * & <args_1>) Line 1515	C++
 	mozjs.dll!js::GCMarker::processMarkStackTop(js::SliceBudget & budget) Line 1727	C++
 	mozjs.dll!js::GCMarker::drainMarkStack(js::SliceBudget & budget) Line 1560	C++
 	mozjs.dll!js::gc::GCRuntime::drainMarkStack(js::SliceBudget & sliceBudget, js::gcstats::Phase phase) Line 4773	C++
 	mozjs.dll!js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget & budget, JS::gcreason::Reason reason, js::AutoLockForExclusiveAccess & lock) Line 5348	C++
 	mozjs.dll!js::gc::GCRuntime::gcCycle(bool nonincrementalByAPI, js::SliceBudget & budget, JS::gcreason::Reason reason) Line 5666	C++
 	mozjs.dll!js::gc::GCRuntime::collect(bool nonincrementalByAPI, js::SliceBudget budget, JS::gcreason::Reason reason) Line 5779	C++
 	mozjs.dll!js::gc::GCRuntime::gcSlice(JS::gcreason::Reason reason, __int64 millis) Line 5854	C++
 	[External Code]

 

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing

  • Recently Browsing   0 members

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