Posts made by MichaIng

Same problem here, since a longer while already:

• Favicons take about a minute to load.
• But it is not like that it takes a minute for every tab, once that particular tab is opened. Instead, once loading a favicon is triggered, some internal system hangs for about a minute: during this minute one can open further tabs which use favicons the one or the other way, and all of them on all open tabs will show up at once, after the ~minute triggered by the very first tab finished, even if the last new tab was opened just a second earlier.
• Once all currently "requested" tabs showed up, any new tab triggers a new minute hang.
• This does not only affect the favicons on the address bar, but also bookmarks/speed dial icons (for the latter only those inside a folder), if those are based on the favicon.
• Hence whenever opening a speed dial folder or accessing the opera://bookmarks/, all icons based on favicons show some replacement graphic until ~1 minute has passed.
• Also icon/graphics selection when adding a new bookmark from the top right dialog is not possible until the minute has passed, showing just a grey graphic without a way to navigate left/right.
• Most annoying for me is that opera://history/ is empty for a minute, since it also fetches favicons.

Same has been reported years ago, with very same symptoms: https://forums.opera.com/topic/64507/the-favicons-don-t-load

So it is some internal favicon fetching issue which affects a wide range of Opera features. I hope this gets more attention. Fetching a new cub of coffee whenever aiming to browse the history after CTRL+H is not exactly a schedule I can keep up much longer.

@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.

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!

@peterb7 So this is at least one similarity on our affected system opposed to @andrew84, where fullscreen does not cause crashes on Windows 10.

@peterb7 Is it Windows 11 as well in your case?

@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 :).

@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: Yes. just tested a fresh standalone Opera developer, and it crashes, too.

@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

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.