The German Website "https://www.elster.de/eportal/login/softpse" is crashing as soon as you load a "Zertifikatsdatei" in with the search button. You can't even type the passwort beneath, because Opera crashes. Some Crash Reports have already been sent. Had to revert to Version 102.0.4880.56 for now. Waiting for another update or Major New Version 103.

@burnout426: Ah I see, thanks for the explanation.

Thumbnails now get a small pix wide stripe at the bottom which is grey. Why? Looks off and annoying. Reverting to Opera stable 130.0.5847.92. Hope that gets fixed...

@opera-qa-team: Subject: Re: Private window loses address bar focus on launch (Update: Clean profile tested)

Hi everyone,

Quick update: I just did a thorough test using a completely fresh, isolated profile via the --user-data-dir command line switch, and I also completely disabled PowerToys and all other third-party UI/window management tools.

Unfortunately, the issue still persists even in a 100% clean Opera environment. When launching a private window in this virgin state, the address bar still refuses to take focus automatically. This rules out any corrupted local profile settings, extensions, or background customization tools.

Since it happens on a clean profile but only started with the v131 update, there must be a specific interaction between the new build's window initialization code and certain Windows 11 system/hardware configurations (e.g., display scaling, GPU acceleration, or multi-monitor environments) that causes the DWM (Desktop Window Manager) or Opera itself to drop the focus hook right after rendering the private landing page.

Is there any specific debug log I can provide to help you track down what happens to the focus in that split second during launch?

For context regarding my system setup: I am using a high-fidelity display configuration and have forced the sRGB color profile via opera://flags to manage color accuracy. Since private windows initialize with a completely different theme/color scheme compared to regular windows, I highly suspect that the v131 update introduced a slight timing or rendering conflict between Opera's private UI initialization, forced color profiles, and the Windows Desktop Window Manager (DWM), which ultimately causes the address bar to lose focus in that split second.

@opera-qa-team: Another quick update: I just did a downgrade test and installed an older build (v130.0.5847.92), which used to work perfectly fine for me in the past. Surprisingly, the issue persists even on the older Opera version with a clean profile.

This completely rules out a regression in the Opera v131 code itself. Instead, it points to a recent change in my Windows 11 environment (likely a recent Windows Update, a GPU driver update, or a persistent system hook from customization tools) that altered how the Windows Desktop Window Manager (DWM) handles window initialization and focus allocation for private Chromium windows.

Since it's not an Opera bug, you can close this investigation! I will have to dig deeper into my OS settings and background services to find out what is blocking the focus hook on system level.

Thanks again for your time and help!

@opera-qa-team: Another quick update: I just did a downgrade test and installed an older build (v130.0.5847.92), which used to work perfectly fine for me in the past. Surprisingly, the issue persists even on the older Opera version with a clean profile.

This completely rules out a regression in the Opera v131 code itself. Instead, it points to a recent change in my Windows 11 environment (likely a recent Windows Update, a GPU driver update, or a persistent system hook from customization tools) that altered how the Windows Desktop Window Manager (DWM) handles window initialization and focus allocation for private Chromium windows.

Since it's not an Opera bug, you can close this investigation! I will have to dig deeper into my OS settings and background services to find out what is blocking the focus hook on system level.

Thanks again for your time and help!

@opera-qa-team: Subject: Re: Private window loses address bar focus on launch (Update: Clean profile tested)

Hi everyone,

Quick update: I just did a thorough test using a completely fresh, isolated profile via the --user-data-dir command line switch, and I also completely disabled PowerToys and all other third-party UI/window management tools.

Unfortunately, the issue still persists even in a 100% clean Opera environment. When launching a private window in this virgin state, the address bar still refuses to take focus automatically. This rules out any corrupted local profile settings, extensions, or background customization tools.

Since it happens on a clean profile but only started with the v131 update, there must be a specific interaction between the new build's window initialization code and certain Windows 11 system/hardware configurations (e.g., display scaling, GPU acceleration, or multi-monitor environments) that causes the DWM (Desktop Window Manager) or Opera itself to drop the focus hook right after rendering the private landing page.

Is there any specific debug log I can provide to help you track down what happens to the focus in that split second during launch?

For context regarding my system setup: I am using a high-fidelity display configuration and have forced the sRGB color profile via opera://flags to manage color accuracy. Since private windows initialize with a completely different theme/color scheme compared to regular windows, I highly suspect that the v131 update introduced a slight timing or rendering conflict between Opera's private UI initialization, forced color profiles, and the Windows Desktop Window Manager (DWM), which ultimately causes the address bar to lose focus in that split second.

Subject: Private window loses address bar focus on launch (Regressed in v131.0.5877.55)

Hi everyone,

I've noticed a frustrating UI regression after updating to the latest Opera stable build (Version: 131.0.5877.55 on Windows).

When opening a new private window (via shortcut or menu), the address bar (Omnibox) does not automatically get focus. If I start typing immediately, nothing happens unless I manually click into the address bar or hit Ctrl + L.

Interestingly, this issue only occurs with new private windows. Regular new windows work perfectly fine and focus the address bar instantly upon launch, just like private windows used to do before the recent update.

It seems like the focus is getting lost or stolen during the initialization of the private browsing landing page. Could the devs please look into this and restore the automatic address bar focus for private windows? It really disrupts the quick-browsing workflow.

Thank you!

@opera-qa-team: Thanks for the reply. As an update to RNA-3261: Even with large files like NVIDIA drivers, the notification dot is missing despite the popup showing 'Download complete'. It seems very inconsistent. Waiting for a fix. Thanks again.

Hello Opera Team,

I am writing to provide feedback regarding the latest UI changes in Opera One (Version: 131.0.5877.24).

In previous versions, there was a very helpful small purple notification dot (a mini-circle) on the top-right of the download arrow icon whenever a download was completed. This allowed users to see at a glance that their file was ready without having to click the icon or wait for the pop-up.

In the current version, this indicator is gone. Currently, there is no visual feedback on the toolbar icon itself after a download finishes. This is a significant downgrade in terms of usability and "Quality of Life."

My request:
Please bring back the notification dot or provide a toggle in the settings to re-enable "Download Completion Indicators" on the toolbar icon. It was a subtle but essential part of the workflow.

Is this a known bug in the current build, or was this a deliberate design choice?

@theory65-0:

Me again

Hi! Based on your screenshot, if it's not a standard pinned tab, here are three likely causes and how to fix them:

1. "On Startup" Settings
   Google might be set as a static startup page in addition to your normal session.

Go to opera://settings/onStartup.

Check if "Open a specific page or set of pages" is selected and if Google is listed there.

If so, remove the entry or switch back to "Retain tabs from previous session".

2. Modified Shortcut Target
   Sometimes the URL is accidentally added to the Opera shortcut itself.

Right-click your Opera shortcut (on Desktop or Taskbar) and select Properties.

Look at the "Target" field. It should end with opera.exe". If there is a URL (like https://www.google.com) behind the quotes, delete it.

3. Corrupt Session Files
   If a session file is bugged, it might "freeze" tabs and force them to reopen every time.

Go to opera://about to find your Profile path.

Close Opera completely.

Navigate to that folder and delete the "Sessions" subfolder. (Note: This will clear all currently open tabs, but it usually fixes persistent "ghost" tabs).

Bonus tip: Since Opera 131 uses Tab Islands, check if that Google icon is actually the start of a collapsed "Island." Try right-clicking the icon and selecting "Separate from Island" or "Close Tab Island."

Hope this helps!

@theory65-0

Try a clean install. Otherwise try a previous Opera Version.

Never had such a behaviour.

If it happens again and again, just file a bug-report and send it to Opera. Maybe you can test it with another PC or Laptop, then at least you know it is your special configuration.

Hope a dev answers your post soon directly, I'm also interested in this one.

Could also be a corrupt installation of the OS, so that TEMP-files mess up in the background. But better let the devs speak for themselves...

@theory65-0

Maybe the first is just a pinned Google-Tab from a previous session? Try unpinning it, then close it. Try a restart. Then it should be gone.

Otherwise it seems like a bug, if it is not a pinned tab.

Thumbnails now get a small pix wide stripe at the bottom which is grey. Why? Looks off and annoying. Reverting to Opera stable 130.0.5847.92. Hope that gets fixed...

Fullscreen black crush / incorrect gamma in Opera 130 (Windows 11 HDR ON, NVIDIA RTX 40 series)
I noticed a regression in Opera 130:
YouTube windowed mode = correct black levels
YouTube fullscreen mode = heavy black crush (too dark)
This only happens when ANGLE uses D3D11 (default).
Workaround:

• Setting opera://flags → ANGLE graphics backend → D3D9 fixes the issue completely.
• OpenGL is not available in Opera 130.
  System:
• Windows 11
• HDR always ON
• NVIDIA RTX 4070 Ti Super
  Looks like a swapchain / HDR tone‑mapping issue in the D3D11 ANGLE path.
  Other Chromium browsers (Chrome/Edge) do not show this problem.
  Please check — fullscreen video should not change black levels.
  Thanks!