Posts made by filbo

@Opera-QA-Team OK, understood, but you should understand that this is a major design flaw. It means any customizations are fragile and volatile. If I conceive of tab islands as little sets of 'where I do xyz' -- who is to say how many tabs a particular purpose needs at any one moment? It can easily fluctuate down to just one.

It could even go down to zero. The feature would be more useful if we could mark an island as 'persistent' and it would survive even down to zero tabs (then it would just be a small hoverable lozenge, of the chosen color & title, responsive to right-click > open a tab in this forlorn island...)

Tab island customizations vaporize automatically?

I created a tab island with 'new tab in tab island'. Changed the color of the tab island. Closed the 2nd tab (still blank). Island disappeared, no color.

If I'm going to the trouble of decorating the islands, I want them to be persistent, even if the island temporarily shrinks down to 1 tab.

I received opera-beta 126.0.5750.30 and opera-stable 126.0.5750.37 in the same apt-get dist-upgrade.

Both had Debian changelog entries pointing to:

http://www.opera.com/blogs/desktop/changelog-for-126/#b5750.30
http://www.opera.com/blogs/desktop/changelog-for-126/#b5750.37

both of those '#' anchors were ineffective. And both of those changelogs (on the same page) point to this same blog post; there is no pointer to a blog post for the opera-stable .37 update. (I do see it below, and will follow that link. But the links published in the .deb metadata are wrong.)

@filbo: Arghh, no, I really want Classic Tabs to work again. Its 'Open all tabs next to the active tab' is what I want.

Thing that isn't working now: right-click an item on my bookmarks bar > Open in new tab; it opens on the end of the tab bar.

Or middle-click, or Ctrl+click, a bookmark bar item. I want these all to open next to my current tab.

I tried right-click bookmark > Open in new tab [ while holding SHIFT, CTRL, or ALT ] -- these didn't change behavior. Maybe one of them could mean 'next to current'? (ALT made the right-click menu go away, but I was able to [ press-and-hold ALT; right-click bookmark > Open in new tab ]. Which made no difference.)

So what I really want is a setting like Classic Tabs's 'Open all tabs next to the active tab'.

Alternative things you could do that are at least somewhat helpful:

• default-blank shortcut for 'Open in new tab next to current'
• default-blank shortcut for 'Move out of tab island'
• shift/ctrl/alt modifier on open-a-tab actions which means 'next to current'
• shift/ctrl/alt modifier on open-a-tab actions which means 'in island [next to current]'

Going from opera-developer 126.0.5748.0 to 127.0.5776.0, the old extension 'Classic Tabs' (https://addons.opera.com/en/extensions/details/classic-tabs) seems to stop working.

What I want it for: Ctrl+T should open new tab next to current tab.

Right-click tab > new tab, does do what I want. But my fingers are used to Ctrl+T!

Best solution: please add a shortcut (blank by default) for 'new tab next to current tab'. Then I can clear 'New tab' shortcut, set 'New tab next to current' to Ctrl+T, and I don't need some funky old extension.

Thanks!

[ workaround: I set Ctrl+T to 'new tab in island', but this is not exactly what I want; it makes a new tab in the right place, that I have to de-island. um. Can you also add a 'Move out from tab island' shortcut (default blank)? ]

An ongoing issue with how Opera is framed on my desktop. First, I'm running Debian 'sid' with what I believe is its most default windowing environment: Gnome (49.1) with its Mutter window manager, a Wayland session, and 'adwaita' theme.

Long ago, Opera offered to frame its windows with the operating system / window manager's widgets, or Opera's own; but I can no longer find this option, so the only choice is 'Opera's own'; which means the window lacks normal widgets like 'close', 'minimize', etc. But it still has a drag handle area in the top bar (small bits of it, away from the various browser widgets).

The problem: subwindows also lack these widgets, and do not have a drag area. I am thinking particularly of the Inspector window, when it is detached from the browser window. It has no place to grab and drag.

So in sum: Linux:Gnome:Mutter:Wayland:Opera, detached Inspector window has no window manager widgets, particularly no drag area.

Image of truncated top bar situation

@filbo aaaand... confirmed the crash bug. Steps:

1. messages.google.com -- then do whatever setup is required for them to mirror your phone's SMS/RCS onto that site (might work without that -- not tested)

2. '⋮' menu on per-chat-top-bar of site > Send feedback

3. enter any text into 'Description' box

4. 'Capture screenshot'

5. dialog pops up, 'Allow messages.google.com to see this tab?'

6. click [Allow]

7. Opera crashes instantly

Starting with this release (but potentially a bit earlier as I may not have restarted between a couple earlier opera-developer builds): when Opera first starts up, the address bar is truncated. I see something like 30-35 chars worth, then a slight fade, then just empty background (as if the URL were only that long, but it is not).

This is visible on multiple tabs. As soon as I click inside the address bar, the full contents become visible, and this 'sticks' and fixes the address bar appearance on all tabs, for the rest of the session.

(Also: learned this because a web site crashed Opera. The site was messages.google.com, their web-access-to-SMS/RCS site. I had operated its '...' menu > Send feedback, wrote them a bug report, clicked on their 'take screenshot' button, got as far as telling it to actually take the screenshot -- and Opera restarted. Have not tried to reproduce this since then, not particularly enjoying sudden browser restarts...

Obviously these are two separate bugs for you to look into... : )

@sopronman: they're phasing out the beta build, leaving only 'stable' and 'dev' builds (but adding an 'early bird' setting to the stable build). Not sure why none of the Opera employees have mentioned it. Here is the blog post: https://blogs.opera.com/desktop/2025/12/opera-presents-early-bird-mode/

@kilian01: no, you are misusing the packaging system. dpkg -i will install any package regardless of whether its dependencies are met. That is its role. apt et al are in charge of the higher level, including paying attention to dependencies. It is like... dpkg -i is you with a screwdriver and some random memory DIMMs, clicking then into your motherboard without checking for compatibility. While apt is you using a tool like pcpartspicker or paying a store to install RAM they've selected as compatible with your system. You can download any .deb from your OS's repo with apt download name-of-package, then install it with dpkg -i name-of-package_version_you_received.deb -- and the resulting installed package will fail in similar ways if you didn't grab its dependencies. The OS's packages -- and Opera -- have met their responsibility by recording those dependencies in the .deb metadata. apt implements paying attention to them. dpkg is a more internal tool and it has to allow installing packages without their dependencies (otherwise some early stages of system install could not work, as the most basic packages circularly depend on each other).

@filbo: argh, I failed at formatting the setuid instructions. But, you shouldn't really do that anyway. Just install properly with apt install and the postinst script will handle the setuid.

@kilian01: I see 3 separate sets of issues in your log, unclear which of them might be relevant. First, easiest to fix, the sandbox binary has wrong permissions:

$ cd /usr/lib/x86_64-linux-gnu/opera-stable
$ sudo chown root opera_sandbox
$ sudo chmod 4755 opera_sandbox

Try after that.

But that is probably actually caused by the 2nd problem: the deb you're installing depends on 4 others, parts of your distro, which are not installed. Because of that it never finished installing, never ran /var/lib/dpkg/info/opera-stable.postinst which would have set up that setuid.

Package libqt5core5a is not installed.
Package libqt5gui5 is not installed.
Package libqt5gui5-gles is not installed.
Package libqt5widgets5 is not installed.
dpkg: error processing package opera-stable (--install):
dependency problems - leaving unconfigured

This not only leaves Opera unconfigured, but also missing libraries it depends on.

dpkg -i is the lowest level package installer. It is not meant to handle package dependencies; those belong to the higher APT subsystem. Try running instead: sudo apt install opera-stable_125.0.5729.21_amd64.deb. This will automatically pull in the packages it depends on.

The 3rd issue is a crash:

Trace/breakpoint trap (core dumped)

but that might be caused by the other two issues, so ignore it for now.

@burnout426: that was fixed in a way that should self-repair successfully on package update.

(and no, there was not a second window, I checked pretty carefully. Just one window with 14x FB + 1x Opera has been updated, counted as 26 tabs being closed.)

Whee, 'You can only post once every 120 second(s) - please wait before posting again'

After posting that, I tried to get out of the situation. First I made a backup of ~/.config/opera-developer; then I closed the 126.0.5742.0 window. At that point the 125.0.5720.0 window went crazy, suddenly replacing every tab with a bunco of old Facebook tabs.

So I closed the 125.0.5720.0 window. Once I was sure no Opera processes were running, I completed the update to 126.0.5744.0, then started it, and of course it was a bunch of old Facebook tabs. Specifically, 14 of them, plus an 'Opera has been updated' tab. But when I tell it to close the window, it prompts me that 26 tabs are being closed(?!?).

Closed it. Moved aside ~/.config/opera-developer, replaced it with the backed-up copy. Started 126.0.5744.0 -- and it has my expected current set of tabs.

So, something very wrong with the singleton stuff; and, probably expected shenanigans when unintentionally running 2x simultaneous Opera processes out of the same config directory. Except the '15 tabs = 26' thing is weird.

Two issues, probably not version-specific, but here we go...

TLDR: (1) 'singleton' intended to keep multiple Opera processes from co-running not working; (2) tons of defunct opera-autoupdat processes.

First issue:

(1) my currently running opera-developer is (was) 125.0.5720.0
(2) I allowed the system (Debian 'sid') to update opera-developer several times without actually restarting the process (so 125.0.5720.0 is still running, but something else is in the filesystem; a frequently-changing 'something else' as you issue more updates
(3) today I right-clicked on a URL in my terminal (actually the changelog for 126.0.5744.0, which is queued to be updated) -> Open -- this caused opera-developer 126.0.5742.0, the currently installed-on-filesystem version, to start a new window containing the same tabs as the currently (and still) open 125.0.5720.0 process.
(4) on examination, ~/.config/opera-developer/Singleton* exist and are dated ~10 minutes ago, i.e. when the 126.0.5742.0 process started. The 5742.0 process has SingletonSocket open for listening.
(5) two different directories exist in /tmp, with different SingletonSockets, each of which is open by one of the processes; but the symlink from ~/.config/opera-developer has been changed. I don't see how 'singletons' are 'single' when they rely on a replacable symlink which the program replaces automatically!

Second issue: there are some 600+ defunct 'opera-autoupdat' processes, children of the 125.0.5720.0 process; it seems to have started about 100/day on Dec 5-6-7-8-9-10 (starting with 5 on Dec 4). These might have started when 126.0.5734.0 was installed in place of 125.0.5727.1 (Dec 4 19:44). Unfortunately ps doesn't show exact start times of defunct processes from days ago.

In any case, the parent process of opera-autoupdat should be wait()ing those processes!

@opera-qa-team: I understand what you're saying, but it is self-inconsistent (there was a release in between those two, which mentioned only two bugs). And it is negative to the viewer of the changelogs. I checked the similarity because as I was scanning the newer list, it seemed hauntingly familiar.

If you didn't expect anyone to look at the changelogs, there is no point in posting them. On the other hand, if you do expect people to look at them, please curate them so that they present only new, useful information. It is ok (i.e.: highly encouraged) to say something like 'this release includes all of the fixes mentioned in the changelog for prior release (123.456.whatev)'.

The changelog for 125.0.5729.12 lists almost all of the bugs mentioned for 125.0.5720.0; plus a few more. Contrast to none of the bugs from 125.0.5707.0 being repeated. Was there some glitch in assembling the list for 5729?