@honoriscreed: type 'stamp' into the search box in Options, turn off the last matching option. Come to the support group fb.com/groups/SocialFixerUserSupport

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

@coder-256 According to the git history, Tampermonkey went closed-source after version 2.9, in early 2013. So it has been that way for 6 years.

Opera's blacklisting of it was far more recent. I would like to hear their reason for doing so; especially as they did not blacklist the ID of the TM version found in their own 'store'.

I reported the listing to the Tampermonkey folks at https://github.com/Tampermonkey/tampermonkey/issues/635

Opera's blacklist of extensions is at https://extension-updates.opera.com/static/omaha/blacklist.txt and appears to be in chronological order of addition to the list. TM is the 2nd last entry; they must have added the last two at the same moment.

Since this was reawakened: the file I previously pointed to (https://extension-updates.opera.com/static/omaha/blacklist.txt) no longer exists; but TM is still blacklisted by Opera. It appears in my Preferences file -- certainly not by my preference, but injected there by Opera.

Opera! There is no reason to be blacklisting Tampermonkey non-beta.

@derjanb got some sort of response from them a long time ago, some sort of guff about TM being force-installed into people's Opera installations by some sort of malware, then used to run the malware's browser extension. Great. That is a bug, misfeature, attack, however you want to characterize it, ON THE PART OF THE MALWARE, not Tampermonkey!

And whatever that malware was, years ago, it is surely handled by people's antivirus etc. these days.

Please un-blacklist TamperMonkey non-beta, ID 'dhdgffkkebhmkfjojejmpbldmpobfkfo', from the Chrome 'store'. And the one from Opera 'store', but I don't know its non-beta ID as you've hidden it in the web UI.

See also DNAWIZ-49270; github.com/Tampermonkey/tampermonkey/issues/635

There were also comments about it on some of the beta blog posts, but those posts now have zero comments at all (https://blogs.opera.com/desktop/2019/01/opera-59-0-3187-0-developer-update/#comment-4270524260) -- ???

BTW @derjanb you said the Opera 'store' edition would update alongside the Firefox edition, about every 3mo. https://addons.opera.com/en/extensions/details/tampermonkey-beta/ is on 4.13.6138, updated 2021-06-22, while FF is on 4.16.6160, updated 2022-04-05.

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

I entered an ASCII smiley, ' : ) ', in my comment [repeating it: ]. It shows up as a broken image when viewing it -- in opera-developer 125.0.5720.0.

Oddly, the HTML element producing this broken image has a link to https://forums,opera,com/assets/plugins/nodebb-plugin-emoji/emoji/emoji-one/1f642.png?v=brc2p4ov9m2 (link intentionally made invalid) -- which is a good, existent, image of a smiley. The HTML also has both 'title=[ascii smiley]' and 'alt=[unicode smiley]'. NONE of the alternative renditions shows up! This seems like some sort of bug in Opera (perhaps the forum software is also contributing, but fundamentally Opera should be able to make something displayable out of all those alternatives!)

Hi,

Thank you for including a link to the changelog post in the .deb package changelog!

And, thanks for so quickly fixing the address bar crash I reported as CRASH-9486 (shown as RNA-1447 in the changelog -- I surely wasn't the first to report it!