Posts made by filbo

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?

@leocg It had an editable 'post a comment here' box, which failed when I tried to submit. If it isn't intended to allow comments, please don't offer a comment box?

Tried to comment on the changelog post, but it failed with:

We are experiencing some problems. Please try again later.
ID: 1764681981.

So I'm posting it here instead.

=====

When viewed in Android Chrome (and probably others), the changelog is formatted such that long lines are truncated, and does not allow 'zoom out', nor horizontal scrolling.

So for instance the 3rd item reads:

DNA-124040 AddressFieldHelperClipboardTest.G|
fails randomly

(where 'G|' is actually about 80% of a 'G').

Please fix the CSS to allow h-scrolling, or allow breaking word wrap.

A simple workaround for this install issue: cd /usr/bin; sudo ln -is opera opera-stable.

This can be done before the install; or after a failed / partial install. Then run apt reinstall opera-stable to finish.

@opera-qa-team: same thing as @thelamer

The Linux APT .deb for opera-stable (specifically) is failing on install due to:

update-alternatives --install /usr/bin/x-www-browser x-www-browser /usr/bin/opera-stable 120 \                                                                  --slave /usr/share/man/man1/x-www-browser.1.gz x-www-browser.1.gz /usr/share/man/man1/opera-stable.1.gz                                         update-alternatives --install /usr/bin/gnome-www-browser gnome-www-browser /usr/bin/opera-stable 120 \                                                          --slave /usr/share/man/man1/gnome-www-browser.1.gz gnome-www-browser.1.gz /usr/share/man/man1/opera-stable.1.gz

-- which tries to link /usr/bin/opera-stable as /usr/bin/{x,gnome}-www-browser. Since the binary is /usr/bin/opera (sans -stable), this fails.

I note that it fails despite the priority 120 being lower than other choices (which means it will never in fact need to follow the path you've supplied). This seems like a tiny bug in update-alternatives(1), fwiw.

This should be fixed by changing the code to tell it to link /usr/bin/opera. You could also actually rename the binary, but if you do that, there will be many other changes elsewhere in your packaging, so I wouldn't go that way.

Meanwhile, your code also has a few other anomalies in this area. The postinst scripts for opera-developer, opera-beta, and opera-stable all give the same priority of 120. Other browsers give a higher priority to their 'stable' branch and successively lower for less stable branches.

And you instruct it to link man pages which do not in fact exist. This apparently doesn't bother update-alternatives even if your candidate is the winner, oddly enough.

@filbo this is now fixed -- apparently by the blog software engineers, since the smileys now show up in both Opera and Edge, both not-updated since the problem was seen.

... which means, there is still some sort of display engine bug in the base Chromium; the Opera blog just isn't triggering it any more. I hope the underlying bug has been reported upstream...

The <alt> is showing up, it's just hidden underneath the 'broken image' image.

Editing the HTML in the inspector: if I change the link to a different PNG (share-article-etc.png from near the top of the page) -- it displays.

Viewing the same page in other Chrome-based browsers, the image is broken. Viewing in Firefox, it's intact. So it's some Chrome / Blink / etc. bug.