Crash in Embedded WebKit on macOS 15.4 (ARM64) with Eclipse 4.35.0 #1978

jschmied · 2025-04-02T09:17:42Z

System Info:

OS: macOS 15.4 (Sonoma)

Architecture: Apple Silicon (ARM64)

JVM: Eclipse OpenJ9 VM 21.0.6.0 (build openj9-0.49.0, JRE 21 Mac OS X aarch64-64-Bit 20250121_371 (JIT enabled, AOT enabled)

Eclipse: 4.35.0 (Build ID: 4.35.0.20250306-0811)

SWT Library: libswt-pi-cocoa-4968r13.jnilib

System Integrity Protection: Enabled

Crash Summary:

The Eclipse application crashes with a SIGABRT due to EXC_BAD_ACCESS (null pointer dereference) in the main UI thread.

The crash originates in the WebKit engine via the SWT Cocoa integration, specifically in layout management:

WebCore::BackForwardCache::markPagesForContentsSizeChanged
WebCore::LocalFrameView::setContentsSize
...
WebHTMLView layoutToMinimumPageWidth
...
Java_org_eclipse_swt_internal_cocoa_OS_objc_msgSendSuper

Steps to Reproduce:

Launch Eclipse 4.35.0 on macOS 15.4 using an ARM64 JDK.

Interact with the editor window (key, mouse)

Eclipse abruptly terminates with a crash report indicating SIGABRT and JVM abort. (about every 20 min)

Crash Report Snippet:

Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Termination Reason:    Namespace SIGNAL, Code 6 Abort trap: 6
...
libjvm.dylib           os::abort()
WebCore                markPagesForContentsSizeChanged
WebKitLegacy           -[WebHTMLView layoutToMinimumPageWidth:...]
libswt-pi-cocoa-4968r13 Java_org_eclipse_swt_internal_cocoa_OS_objc_msgSendSuper

The text was updated successfully, but these errors were encountered:

Phillipus · 2025-04-02T10:00:47Z

Same for me also on Eclipse 2024-12 (4.34) and 2024-06 (4.32):

crash.txt

Eclipse 2024-12 (4.34) or 2024-06 (4.32)
OpenJDK 64-Bit Server VM Temurin-21.0.6+7
macOS 15.4 Sequoia (not crashing on Sonoma 14.7.4)
WebKit 20621.1.15.11.10
ARM Mac Mini M4

Steps to reproduce for me are:

Ensure Javadoc View is closed
In a Java Editor hover over code so that the Javadoc displays in a popup, and ensure to move the mouse into the Javadoc popup so that it gets focus and scrollbars are shown in the popup.
Open the Javadoc View
Hover over code again as in (2)
Crash

Perhaps a regression introduced in macOS 15.4.

Unfortunately this makes Eclipse on Mac unusable when using Webkit in any way.

jschmied · 2025-04-02T10:05:27Z

Switch zu external Browser (General->Webbrowser) and save often. Then you can work with some crashes.

Phillipus · 2025-04-02T10:07:06Z

Switch zu external Browser (General->Webbrowser) and save often. Then you can work with some crashes.

This won't help. Webkit is used internally for the Javadoc. Eclipse is crashing for me very minute or so just by working in a Java editor.

ivy-lli · 2025-04-02T11:03:06Z

Same problem for me.

Eclipse 2025-03 (4.35)
OpenJDK 64-Bit Server VM Temurin-21.0.6+7
macOS 15.4
ARM Mac M2 Pro

Phillipus · 2025-04-02T11:03:36Z

Different way to reproduce

Ensure Javadoc View is open
In a Java Editor hover over code so that the Javadoc displays in a popup, and ensure to hover the mouse into the Javadoc popup so that scrollbars are shown in the popup
Click into the Java Editor so that it tries to update the Javadoc View
Crash

Phillipus · 2025-04-02T11:10:23Z

I think a key thing here is to ensure that the vertical scroll bar appears in the Javadoc hover and the Javadoc View gets updated. The crash log suggests this may have something to do with it:

Stack: [0x000000016ed30000,0x000000016f52c000],  sp=0x000000016f527b50,  free space=8158k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [WebCore+0x1dbe5e8]  WebCore::BackForwardCache::markPagesForContentsSizeChanged(WebCore::Page&)+0xe4
C  [WebCore+0x2382364]  WebCore::LocalFrameView::setContentsSize(WebCore::IntSize const&)+0x104
C  [WebCore+0x238318c]  WebCore::LocalFrameView::adjustViewSize()+0x60
C  [WebCore+0x23a0b7c]  WebCore::LocalFrameViewLayoutContext::performLayout(bool)+0x660
C  [WebCore+0x2385ff8]  WebCore::LocalFrameViewLayoutContext::layout(bool)+0x3c
C  [WebKitLegacy+0x106d0]  -[WebHTMLView layoutToMinimumPageWidth:height:originalPageWidth:originalPageHeight:maximumShrinkRatio:adjustingViewSize:]+0xf0
C  [WebKitLegacy+0xcf0c]  -[WebDynamicScrollBarsView(WebInternal) updateScrollers]+0x88
C  [WebCore+0x1249c5c]  WebCore::ScrollView::platformSetScrollbarModes()+0x28
C  [WebCore+0x178c0]  WebCore::ScrollView::setScrollbarModes(WebCore::ScrollbarMode, WebCore::ScrollbarMode, bool, bool)+0xfc
C  [WebCore+0x2386fac]  WebCore::LocalFrameView::willDoLayout(WTF::WeakPtr<WebCore::RenderElement, WTF::SingleThreadWeakPtrImpl, WTF::RawPtrTraits<WTF::SingleThreadWeakPtrImpl>>)+0x434
C  [WebCore+0x23a0920]  WebCore::LocalFrameViewLayoutContext::performLayout(bool)+0x404
C  [WebCore+0x2385ff8]  WebCore::LocalFrameViewLayoutContext::layout(bool)+0x3c
C  [WebKitLegacy+0x106d0]  -[WebHTMLView layoutToMinimumPageWidth:height:originalPageWidth:originalPageHeight:maximumShrinkRatio:adjustingViewSize:]+0xf0
C  [WebKitLegacy+0xd32c]  -[WebDynamicScrollBarsView(WebInternal) updateScrollers]+0x4a8
C  [WebCore+0x1249c5c]  WebCore::ScrollView::platformSetScrollbarModes()+0x28
C  [WebCore+0x178c0]  WebCore::ScrollView::setScrollbarModes(WebCore::ScrollbarMode, WebCore::ScrollbarMode, bool, bool)+0xfc
C  [WebCore+0x238121c]  WebCore::LocalFrameView::~LocalFrameView()+0x68
C  [WebCore+0x2381f2c]  WebCore::LocalFrameView::~LocalFrameView()+0x10
C  [WebCore+0x14d5c8]  WebCore::CachedFrame::clear()+0xc0
C  [WebCore+0x14d2dc]  WebCore::CachedFrame::destroy()+0x37c
C  [WebCore+0x14cebc]  WebCore::CachedPage::~CachedPage()+0x24

ivy-lli · 2025-04-02T11:16:01Z

Temporary fix, so it should no longer crash from the JavaDoc: disable the hover tooltips (Preferences -> Java -> Editor -> Hovers -> Untick Combined Hover)

Phillipus · 2025-04-02T11:18:16Z

Temporary fix, so it should no longer crash from the JavaDoc: disable the hover tooltips (Preferences -> Java -> Editor -> Hovers -> Untick Combined Hover)

Seems to be the only course of action.

Phillipus · 2025-04-02T11:20:09Z

I guess we need to figure out if the crash is only happening with the Javadoc hover popups or in other uses of WebKit on Mac. I'm testing a simple Browser component snippet and can't make it crash.

This is only happening since Sequoia 15.4 released on March 31 2025
Crashing on Eclipse since at least 4.32 (I didn’t test older versions) and on latest 4.35
Seems to be triggered by Javadoc hover popups with scrollbars
Having the Javadoc View open at the same time might be a factor (it exacerbates the problem, but the crash can occur without it being open)
Is this only happening in Javadoc hover popups, or in other uses of Webkit?
Is this an Apple bug or WebKit bug?
Is this something that can be fixed in SWT or Javadoc popup code?

Phillipus · 2025-04-02T13:18:19Z

It might be worth opening an issue at WebKit. But I don't know if they might throw it back to SWT/JDT UI/another component here. As this only seems to be triggered when using Javadoc hover popups it might be something that could be worked around in that component.

Could someone advise on best course of action?

Phillipus · 2025-04-03T09:12:57Z

@jschmied As you are the original issue reporter, do you think you might open an issue at WebKit?

jschmied · 2025-04-03T09:21:40Z

https://bugs.webkit.org/show_bug.cgi?id=290985

Phillipus · 2025-04-03T09:24:03Z

https://bugs.webkit.org/show_bug.cgi?id=290985

Thanks! Perhaps you could add a link to this report there?

BeckerWdf · 2025-04-03T09:45:05Z

Thanks! Perhaps you could add a link to this report there?

I think the link is already there

Phillipus · 2025-04-03T09:45:42Z

I think the link is already there

Yes, it is now. Thanks @jschmied

soethoff · 2025-04-09T14:00:59Z

Our primary macOS team at SAP has filed an incident with Apple regarding this issue. We received feedback from them that they are currently working on a solution. Here’s a quote from the incident that I obtained from my colleague:

I confirmed our engineering team is aware of this issue and I expect it will be addressed in an upcoming software update. I will follow up once we have more information.

Hopefully, the version 15.4.1 (or however it will be called) will be released as soon as possible.

Phillipus · 2025-04-09T14:04:18Z

The bug at https://bugs.webkit.org/show_bug.cgi?id=290985 has been changed to a "Security" issue. This means that it's not accessible to anyone not on the cc list. I'm on the cc list of the bug and the last response was a pull request from an Apple engineer on 4 April.

C4J · 2025-04-09T14:08:14Z

Thanks for the update - please keep us informed.

jschmied · 2025-04-09T16:09:46Z

Workaround is to switch off Java->Editors->Hover-> "combined hover" until we get a bugfix

C4J · 2025-04-09T16:32:46Z

Thanks for that - most helpful.

…

On 9 Apr 2025, at 17:10, Jürgen Schmied ***@***.***> wrote: jschmied left a comment (eclipse-platform/eclipse.platform.swt#1978) Workaround is to switch off Java->Editors->Hover-> "combined hover" until we get a bugfix — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread. <#1978 (comment)> <https://github.com/notifications/unsubscribe-auth/AE4Z2TRNA5A564AZ7AU2AOL2YVA6BAVCNFSM6AAAAAB2JAOYXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJQGIZDSMJTGU> jschmied left a comment (eclipse-platform/eclipse.platform.swt#1978) <#1978 (comment)> Workaround is to switch off Java->Editors->Hover-> "combined hover" until we get a bugfix — Reply to this email directly, view it on GitHub <#1978 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE4Z2TRNA5A564AZ7AU2AOL2YVA6BAVCNFSM6AAAAAB2JAOYXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJQGIZDSMJTGU>. You are receiving this because you are subscribed to this thread.

sgjohnston · 2025-04-09T16:51:37Z

I guess we need to figure out if the crash is only happening with the Javadoc hover popups or in other uses of WebKit on Mac. I'm testing a simple Browser component snippet and can't make it crash.

I'm seeing the same (or very similar) crash when editing TypeScript (Wild Web Developer with generic code editor). Unfortunately, I can't work out exactly what is causing the crash, but it is every few 10s of seconds :-(. The stack trace is similar to above so hopefully the same cause. It only started with the update to Sequoia 15.4.

garethedwards · 2025-04-10T11:21:50Z

I'm having this issue and, while otherwise sporadic, I can trigger it with 100% reproducibility when clicking "Open description of rule" in the hover panel of a Sonarlint/SonarQube issue (in both JavaScript or Java code)

The description pane opens momentarily with content partially rendered before Eclipse closes. Nothing is registered in the Eclipse error log

Phillipus · 2025-04-10T11:25:44Z

Nothing is registered in the Eclipse error log

If you navigate to the location of the eclipse executable (for me this is in Eclipse.app/Contents/MacOS/) you'll find a crash log there.

garethedwards · 2025-04-10T11:31:37Z

Nothing is registered in the Eclipse error log

If you navigate to the location of the eclipse executable (for me this is in Eclipse.app/Contents/MacOS/) you'll find a crash log there.

Gotcha - thanks.
Stacktrace shows pretty much the same as the OP and your logs, and indeed points to Webkit's scrollbar calcs

C  [WebCore+0x1dbe5e8]  WebCore::BackForwardCache::markPagesForContentsSizeChanged(WebCore::Page&)+0xe4
C  [WebCore+0x2382364]  WebCore::LocalFrameView::setContentsSize(WebCore::IntSize const&)+0x104
C  [WebCore+0x238318c]  WebCore::LocalFrameView::adjustViewSize()+0x60
C  [WebCore+0x23a0b7c]  WebCore::LocalFrameViewLayoutContext::performLayout(bool)+0x660
C  [WebCore+0x2385ff8]  WebCore::LocalFrameViewLayoutContext::layout(bool)+0x3c
C  [WebKitLegacy+0x106d0]  -[WebHTMLView layoutToMinimumPageWidth:height:originalPageWidth:originalPageHeight:maximumShrinkRatio:adjustingViewSize:]+0xf0
C  [WebKitLegacy+0xcf0c]  -[WebDynamicScrollBarsView(WebInternal) updateScrollers]+0x88

Phillipus · 2025-04-16T18:29:26Z

Just a heads up that the crash is still happening in macOS Sequoia 15.4.1 released today.

soethoff · 2025-04-17T07:55:22Z

Just a heads up that the crash is still happening in macOS Sequoia 15.4.1 released today.

Yes, we received confirmation from Apple that 15.4.1 does not include any WebKit fixes. Similarly, 15.5 beta 1 or 2 also lacks a fix. Apple appears to anticipate a fix in the next beta or the one after that, unless there are any unforeseen circumstances.

@Phillipus: Since you can still access the WebKit bug - Can you see/observe any information about the root cause of the issue? For our tooling, the workaround ‘disable combined hover’ is not applicable, and we are actively seeking an alternative solution.

jschmied · 2025-04-17T08:07:11Z

Last change on webkit bug on 2025-04-04, no further information.

Phillipus · 2025-04-17T08:13:57Z

@Phillipus: Since you can still access the WebKit bug - Can you see/observe any information about the root cause of the issue? For our tooling, the workaround ‘disable combined hover’ is not applicable, and we are actively seeking an alternative solution.

As @jschmied says, the last update was on 2025-04-04 with a pull request from an Apple Engineer. Other than that and an assigned internal Radar number there's no commentary on the issue.

Phillipus · 2025-05-02T22:48:28Z

Still no crashes after restart of the computer.

Same for me. It's as if setting it can't be undone. I also tried deleting the Eclipse .plist in ~/Library/Preferences, re-installing Eclipse, and restarting. I can't imagine where else macOS is storing/caching this.

NigelHambly · 2025-05-04T13:58:12Z

Thanks to all for the report and diagnosis above. I've had exactly the same problem following an upgrade to Sequoia 15.4.1 with an older version of the IDE:

Eclipse IDE for Java Developers (includes Incubating components)
Version: 2022-12 (4.26.0)
Build id: 20221201-1913

(no such problem with any version of MacOS prior to this).

The explanation and work-around given above work for me - thanks so much for this: I would have been utterly lost without it.

adrian-dybwad · 2025-05-06T00:21:51Z

but no restart of the IDE or the computer.

You'd need to do restart to be sure.

Still no crashes after restart of the computer.

Edit: After a few days, it did crash again, so I reapplied the defaults write epp.package.jee WebKitUsesPageCachePreferenceKey -int 0

RobertHammen · 2025-05-06T17:19:29Z

Per Apple this issue should be fixed in macOS 15.5, which just went RC and should release next week. Please test!

aritgithub · 2025-05-07T10:32:44Z

For my old and trusty Eclipse (2021-09 - 4.21.0):

defaults write org.eclipse.platform.ide WebKitCacheModelPreferenceKey -int 0

chrisrueger · 2025-05-08T10:23:37Z

I had to use epp.package.committers instead of epp.package.ee:

defaults write epp.package.committers WebKitUsesPageCachePreferenceKey -int 0

So it depends on the Eclipse package type you have selected for installation.

The macOS error report shows it too (in addition to the Info.plist file mentioned above)

Process:               eclipse [90003]
Path:                  /Applications/Eclipse.app/Contents/MacOS/eclipse
Identifier:            epp.package.committers
Version:               4.35.0 (4.35.0.20250306-0811)
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
User ID:               501

Date/Time:             2025-05-08 12:16:54.7687 +0200
OS Version:            macOS 15.4.1 (24E263)

Phillipus · 2025-05-09T11:58:19Z

I discovered another option that works to stop the crash:

defaults write <appid> WebKitCacheModelPreferenceKey -int 0

or

defaults delete <appid> WebKitCacheModelPreferenceKey

If this key is present in your ~/Library/Preferences/<appid>.plist file the value is 1 and this enables the cache. Setting it to 0 will work.

This explains why I was unable to re-create the crash when I deleted my <appid>.plist file. It seems that if the WebKitCacheModelPreferenceKey key is not present then it defaults to 0 and so setting WebKitUsesPageCachePreferenceKey makes no difference because the cache is disabled anyway.

So the crash is triggered by the combination of the following in <appid>.plist:

WebKitCacheModelPreferenceKey = 1 (default is 0)
WebKitUsesPageCachePreferenceKey = 1 (default is 1 so, if not present, is effectively 1)

So, yet another way to workaround the crash is to simply delete the ~/Library/Preferences/<appid>.plist file.

Phillipus · 2025-05-12T13:29:44Z

I discovered another option that works to stop the crash:

defaults write <appid> WebKitCacheModelPreferenceKey -int 0

or
defaults delete <appid> WebKitCacheModelPreferenceKey

Actually, don't do that as it's set back to the value of 1 when the File Open dialog is opened in Eclipse.

I don't know if there's something in the native Mac SWT code that sets this key but I think it should not be set to 1.

Phillipus · 2025-05-12T19:34:22Z

Not fixed in macOS 15.5 released today. Still crashes. (Workaround still works).

crash.txt

Phillipus · 2025-05-13T06:44:02Z

Still crashes.

Let's be clear about this. Eclipse can crash when using hover tooltips and the JavaDoc view if ~/Library/Preferences/<appid>.plist contains the WebKitCacheModelPreferenceKey key with a value of 1. Like this:

<key>WebKitCacheModelPreferenceKey</key>
<integer>1</integer>

As the .plist file is in binary format the way to check this is to navigate to the file in Finder, select it, and press the Space bar to preview it.

Here's what I've done now since macOS 15.5:

Quit Eclipse
Delete the ~/Library/Preferences/<appid>.plist file
Restart the Mac to ensure that the .plist file is not cached
Restart Eclipse

The ~/Library/Preferences/<appid>.plist is now recreated when re-opening and quitting Eclipse but it does not (so far) re-add the WebKitCacheModelPreferenceKey key to the file. So maybe something was changed in that regard. I'll monitor it to see if some action in Eclipse adds it back again.

soethoff · 2025-05-13T10:27:31Z

Interesting findings, @Phillipus! Until now, I couldn’t reproduce the issue on my machine(s). However, in all Eclipse .plist files, the WebKitCacheModelPreferenceKey key was missing.

After manually adding both keys with the value 1, Eclipse crashes.

Unfortunately, this issue also occurs on macOS 15.5.

So, it seems that the initial issue hasn’t been resolved.
It would be helpful to understand why and when the WebKitCacheModelPreferenceKey key is added.
I’ll also try to gather more information from my colleagues about their work environments and any changes they’ve made.

Phillipus · 2025-05-13T10:32:41Z

After manually adding both keys with the value 1, Eclipse crashes.

You only need to add this one key to get it to crash:

<key>WebKitCacheModelPreferenceKey</key>
<integer>1</integer>

It would be helpful to understand why and when the WebKitCacheModelPreferenceKey key is added.

Before macOS 15.5 I observed it being created when I opened an Open File dialog in Eclipse, and then quit Eclipse (I think that's when the .plist file is flushed and written to file).

~~Since macOS 15.5, and after deleting my .plist file, I no longer see this key being created when using Eclipse. Perhaps this was a change in 15.5?~~ Edit - it is still created.

jschmied · 2025-05-13T13:43:14Z

https://nvd.nist.gov/vuln/detail/CVE-2025-31257 should be fixed in 18.5

Phillipus · 2025-05-13T13:46:15Z

https://nvd.nist.gov/vuln/detail/CVE-2025-31257 should be fixed in 18.5

I think you mean 15.5.

But it isn't fixed in macOS 15.5 if Eclipse's .plist file contains this:

<key>WebKitCacheModelPreferenceKey</key>
<integer>1</integer>

See #1978 (comment)

I added a comment to this effect in the WebKit Bugzilla.

Phillipus · 2025-05-13T14:04:49Z

And to prove that this is absolutely reproducible I did this:

defaults write org.eclipse.sdk.ide WebKitCacheModelPreferenceKey -int 1

And then did some JavaDoc hovering and then opened the JavaDoc View in Eclipse for the attached crash...

crash.txt

orhan-swe · 2025-05-15T10:16:42Z

on 15.5 I deleted ~/Library/Preferences/.plist file
It worked fine for a full day, the next day it crashed again. In the new .plist I could again find

<key>WebKitCacheModelPreferenceKey</key>
<integer>1</integer>

Now it is crashing all the time. So I will have to delete .plist again..
So this is not fixed and the delete .plist file is not a good WA as the key will be re-added to the file at some point. So will probably have to use the old WA and Untick Combined Hover, which I really do not want to do..

Phillipus · 2025-05-15T10:22:50Z

@orhan-swe

So will probably have to use the old WA and Untick Combined Hover

You don't have to do that. The original workaround is still valid:

defaults write <app id> WebKitUsesPageCachePreferenceKey -int 0

HoJinLee96 · 2025-05-15T13:44:50Z

LOL dude, THANK YOU SO MUCH! I was going through the EXACT. SAME. BULLSHIT. issue. I swear to god, I was THIS close to yeeting my damn computer out the window.

But then I saw your comment and ran this magical incantation: defaults write WebKitCacheModelPreferenceKey -int 0

AND HOLY CRAP, IT ACTUALLY WORKED?! Been smooth sailing ever since.

You literally saved my computer (and probably my hands from being broken from smashing it). Seriously, you're a legend. Thanks a million! 😂👍

Phillipus · 2025-05-15T13:51:32Z

Please note that defaults write <app id> WebKitUsesPageCachePreferenceKey -int 0 is the most reliable option at this stage.

The credit for this discovery goes to @filipnavara in his comment here.

leerho · 2025-05-16T22:47:28Z

What is the effective difference between the temporary fix suggested by @ivy-lli (Apr 2nd):

Temporary fix, so it should no longer crash from the JavaDoc: disable the hover tooltips
(Preferences/Settings) -> Java -> Editor -> Hovers -> Untick Combined Hover

versus @filipnavara suggestion (Apr 24th):

defaults write org.eclipse.platform.ide WebKitCacheModelPreferenceKey -int 0

So far I have just tried the former -- and no crashes!

Phillipus · 2025-05-17T07:44:12Z

What is the effective difference between the temporary fix suggested by @ivy-lli (Apr 2nd):

You won't see any JavaDoc hover tooltips at all with that (unless with a modifier key).

leerho · 2025-05-17T23:08:30Z

Thanks! Does it matter which folder one needs to execute the

defaults write org.eclipse.platform.ide WebKitCacheModelPreferenceKey -int 0

command?

Phillipus · 2025-05-18T07:23:14Z

Thanks! Does it matter which folder one needs to execute the

defaults write org.eclipse.platform.ide WebKitCacheModelPreferenceKey -int 0

command?

No. The command adds that key and value to the ~/Library/Preferences/<appid>.plist file. But you need to use WebKitUsesPageCachePreferenceKey

leerho · 2025-05-19T00:12:43Z

Well, I ran the defaults ... command and checked the org.eclipse.platform.ide.plist file and WebKitCacheModelPreferenceKey = 0;.

In addition, I reset the Combined Hover check mark, figuring that I didn't need it to be unset.
And after about an hour of editing .... CRASH. I checked the WebKitCacheModelPreferenceKey and it was still 0.

I'm beginning to think that unsetting the Combined Hover may be more reliable than the defaults... command.
Although it is a PITA not to have Javadoc hover capability.

ivy-lli · 2025-05-19T06:01:43Z

Please read the whole thread. It is important that you find the correct ID for your eclipse application, otherwise it will not work. #1978 (comment)
If you run the command correctly it should no longer crash.

The workaround about disabling the JavaDoc hover is only an option to at least make Eclipse work again. However, if you write a lot of Java code, the dev experience is very bad with it.

Phillipus · 2025-05-19T08:56:28Z

@leerho - if you read the thread you'll see that the key that works is WebKitUsesPageCachePreferenceKey not WebKitCacheModelPreferenceKey:

defaults write <app id> WebKitUsesPageCachePreferenceKey -int 0

See #1978 (comment) and #1978 (comment)

leerho · 2025-05-19T18:38:55Z

@ivy-lli , @Phillipus
My mistake! Thank you!

leerho · 2025-05-19T23:25:19Z

@Phillipus
Forgive me, I'm still a little confused. In your comment on:
May 13th
You state that if the key: WebKitCacheModelPreferenceKey 1 exists in the Eclipse *.plist file this problem won't be fixed.

Yet the recommended fix refers to the key: WebKitUsesPageCachePreferenceKey

At the moment my org.eclipse.platform.ide.plist file contains:

WebKitCacheModelPreferenceKey = 1;
WebKitJavaEnabled = :false;
WebKitUsesPageCachePreferenceKey = 0;

Do I need to delete and/or modify the WebKitCacheModelPreferenceKey ?

Phillipus · 2025-05-20T05:49:57Z

Do I need to delete and/or modify the WebKitCacheModelPreferenceKey ?

No. You can delete it if you want but it will eventually be added again (when running Eclipse). WebKitUsesPageCachePreferenceKey with a value of 0 over-rides that.

leerho · 2025-05-21T00:44:48Z

My Eclipse is still crashing, even with my org.eclipse.platform.ide.plist file containing:

WebKitCacheModelPreferenceKey = 1;
WebKitJavaEnabled = :false;
WebKitUsesPageCachePreferenceKey = 0;

In the entire ~/Library/Preferences/ folder there must be over 200 plist files and only two of them start with org.eclipse...
One is related to the oomph installer: org.eclipse.oomph.setup.installer.product.with-jre.restricted.plist
and the other is the one with the above keys: org.eclipse.platform.ide.plist.
So I'm pretty sure it is the right place.

I am running on: MacOS Sequoia 15.5, MacBook M4 Pro
Eclipse 2025-03 (4.35.0)
Maven 3.9.9
Java (JDK): Temurin-24+36

merks mentioned this issue Apr 19, 2025

Eclipse IDE 2025-06 M1 on macOS crashes eclipse-platform/eclipse.platform.ui#2932

Closed

merks marked this as a duplicate of eclipse-platform/eclipse.platform.ui#2932 Apr 19, 2025

Crash in Embedded WebKit on macOS 15.4 (ARM64) with Eclipse 4.35.0 #1978

Crash in Embedded WebKit on macOS 15.4 (ARM64) with Eclipse 4.35.0 #1978

Comments

jschmied commented Apr 2, 2025 • edited Loading

Phillipus commented Apr 2, 2025 • edited Loading

jschmied commented Apr 2, 2025

Phillipus commented Apr 2, 2025 • edited Loading

ivy-lli commented Apr 2, 2025

Phillipus commented Apr 2, 2025

Phillipus commented Apr 2, 2025 • edited Loading

ivy-lli commented Apr 2, 2025

Phillipus commented Apr 2, 2025 • edited Loading

Phillipus commented Apr 2, 2025 • edited Loading

Phillipus commented Apr 2, 2025 • edited Loading

Phillipus commented Apr 3, 2025

jschmied commented Apr 3, 2025

Phillipus commented Apr 3, 2025

BeckerWdf commented Apr 3, 2025

Phillipus commented Apr 3, 2025

soethoff commented Apr 9, 2025

Phillipus commented Apr 9, 2025

C4J commented Apr 9, 2025

jschmied commented Apr 9, 2025

C4J commented Apr 9, 2025 via email

sgjohnston commented Apr 9, 2025

garethedwards commented Apr 10, 2025 • edited Loading

Phillipus commented Apr 10, 2025 • edited Loading

garethedwards commented Apr 10, 2025 • edited Loading

Phillipus commented Apr 16, 2025

soethoff commented Apr 17, 2025

jschmied commented Apr 17, 2025

Phillipus commented Apr 17, 2025

Phillipus commented May 2, 2025

NigelHambly commented May 4, 2025

adrian-dybwad commented May 6, 2025

RobertHammen commented May 6, 2025

aritgithub commented May 7, 2025

chrisrueger commented May 8, 2025

Phillipus commented May 9, 2025 • edited Loading

Phillipus commented May 12, 2025 • edited Loading

Phillipus commented May 12, 2025 • edited Loading

Phillipus commented May 13, 2025 • edited Loading

soethoff commented May 13, 2025

Phillipus commented May 13, 2025 • edited Loading

jschmied commented May 13, 2025

Phillipus commented May 13, 2025 • edited Loading

Phillipus commented May 13, 2025 • edited Loading

orhan-swe commented May 15, 2025 • edited Loading

Phillipus commented May 15, 2025

HoJinLee96 commented May 15, 2025

Phillipus commented May 15, 2025 • edited Loading

leerho commented May 16, 2025

Phillipus commented May 17, 2025 • edited Loading

leerho commented May 17, 2025

Phillipus commented May 18, 2025 • edited Loading

leerho commented May 19, 2025

ivy-lli commented May 19, 2025

Phillipus commented May 19, 2025 • edited Loading

leerho commented May 19, 2025

leerho commented May 19, 2025 • edited Loading

Phillipus commented May 20, 2025

leerho commented May 21, 2025 • edited Loading

jschmied commented Apr 2, 2025 •

edited

Loading

Phillipus commented Apr 2, 2025 •

edited

Loading

Phillipus commented Apr 2, 2025 •

edited

Loading

Phillipus commented Apr 2, 2025 •

edited

Loading

Phillipus commented Apr 2, 2025 •

edited

Loading

Phillipus commented Apr 2, 2025 •

edited

Loading

Phillipus commented Apr 2, 2025 •

edited

Loading

garethedwards commented Apr 10, 2025 •

edited

Loading

Phillipus commented Apr 10, 2025 •

edited

Loading

garethedwards commented Apr 10, 2025 •

edited

Loading

Phillipus commented May 9, 2025 •

edited

Loading

Phillipus commented May 12, 2025 •

edited

Loading

Phillipus commented May 12, 2025 •

edited

Loading

Phillipus commented May 13, 2025 •

edited

Loading

Phillipus commented May 13, 2025 •

edited

Loading

Phillipus commented May 13, 2025 •

edited

Loading

Phillipus commented May 13, 2025 •

edited

Loading

orhan-swe commented May 15, 2025 •

edited

Loading

Phillipus commented May 15, 2025 •

edited

Loading

Phillipus commented May 17, 2025 •

edited

Loading

Phillipus commented May 18, 2025 •

edited

Loading

Phillipus commented May 19, 2025 •

edited

Loading

leerho commented May 19, 2025 •

edited

Loading

leerho commented May 21, 2025 •

edited

Loading