@burnout426: Since I have no vimeo account, I cannot watch this "unrated" video. However, I can just press F11 on any website, also here or in opera settings, to trigger the crash. So while I recognised it first when trying to fullscreen a video with its webplayer GUI, it is irrelevant, as the issue seems in the fullscreen "backend" of the browser. Toggling hardware acceleration and any ANGLE backend does not solve it. ID if the last crash upload: 3cce6274-f34f-4eb3-b1be-4696d2240521
Interestingly, while automatic uploads were disabled before, and no OPERA_CRASH_EMAIL was set, I see a lot of older crash IDs and uploads from earlier May. Not great in terms of privacy, but a different topic.

@burnout426

However, as said, it does not matter how or from where fullscreen is enabled. The crash report was done hitting F11 from the crash reports page.

@burnout426
Not "some" non-video pages trigger it, too, but literally all pages, no matter how fullscreen is enabled, including clicking the fullscreen option on "any" video webplayer GUI and F11.

@burnout426: Yes. just tested a fresh standalone Opera developer, and it crashes, too.

@burnout426: For completeness: I also tried to toggle the 3 fullscreen related flags (typing "fullscreen" into the flag search), but they have no effect on it either.

@burnout426: Thank you very much. Until then, reverting to 111.0.5159.0 works very well, just replacing opera.exe and renaming the autoupdate folder. A native downgrade option would be still nice :).

The issue has been fixed (in my case) with v112.0.5179.0, many thanks!

The crashes when going fullscreen on Windows 11 has been fixed, many thanks!

@burnout426 Ah yes that makes sense. Since it clearly broke with 2nd last Opera developer update, that is the culprit, not Windows update or user password change (which did not happen). I hope such is prevented in Opera stable. Using a developer version as production system could be called own fault :).

@burnout426 yes, that is quite likely, at least as long it is not only a flag, with the old cookies GUI still implemented in Chromium.

@leocg thanks for the info, and what a huge regression . Maybe Opera can bring it back?

I recognised that individual cookies cannot be removed or even seen anymore, but only all cookies for website removed, without any info/list about them. I know with developer options it is possible, but guys, this is such an essential feature, for transparency, security, a lot of practical tasks as well: please re-add it to the lock button GUI beside the address bar, and the settings. Is it this experimental cookies feature flag, which cannot be disabled, but only changed from "undefined" to "enabled"?

@daria19 I did just recognise that it is not the banner (only), but actually the GMX website in general, when accessing from here: https://millionenklick.gmx.net/
When I am at this page, not login or anything, and just click at the "GMX" logo at the top left of the page, a link to plain https://www.gmx.net/, it crashes.

Platform is Windows 11, a portable instance of Opera developer.

Regarding crash report uploads: yes, uploads are done/repeated every time until now. I generally have the impression that some of the settings I do are not permanently stored. It might be related to the structural changes of Opera profile data, where vast parts where shifted into a "Default" sub directory. E.g. also permissions to access camera, microphone, platform notifications etc, are not stored permanently. Camera and microphone access sometimes gets refused in the middle of a WebRTC video session, so that I need to reload the page and grant access again.

I get regular crashes when clicking on a particular type of advertisement banners. This happened some versions earlier, then instead of crashing, it was just a noticeable hang/delay for 2 seconds or so, now it crashes again. Can someone have a look into crash report bp-6d4ee9c2-4255-47e5-805d-3b3b40240917 ?
From the same instance, basically all daily crash reports are based on the same issue.

Side note: at the top of opera://crashes/ it says that the crash report feature is disabled, and I indeed disabled it, but at all below crashes it still shows status uploaded, with a date and ID. I think this is not intended either, and from data privacy stand point not acceptable!

@burnout426 Ah yes that makes sense. Since it clearly broke with 2nd last Opera developer update, that is the culprit, not Windows update or user password change (which did not happen). I hope such is prevented in Opera stable. Using a developer version as production system could be called own fault :).

@burnout426 Thanks, deleting "Login Data" and journal indeed worked. The meta data of old and new file are exactly the same. So this means the format of that file has changed between Opera versions and no migration is done? Would be great to have a way to migrate the old "Login Data", would be absolutely essential at least in stable release, IMO. Could be quite a disaster for many users, it is half one for me.

For me, on Windows 11, since the developer version update before this one, the password manager does not work anymore: it is empty, and adding new passwords does not work. I can select "save" after login somewhere, but checking back at the password manager shows it still empty, and of course also logging in with saved password hence does not work.

@michaing: Additionally, new passwords are not stored. It is always offered to save them, but they do not appear in the password manager and cannot be retrieved for login.

@koimark: Same here, on Windows 11.