Observation regarding repositories is no more relevant here. It belongs to Red Hat Bugzilla – Bug 1733949.

Hi. While Installation process on an RPM package takes place in Gnome Software -be it a third-party software as well-, user gets its very first impression of a software to be installed.

As noticeable here:
1., Icon dedicated to Opera is not provided;
2. there is no snapshot provided, while all is graphical nowadays;
3. Gnome states there is no software repository included.

Once package has been installed on system, under Details section functions such as Localized in your Language, Release Activity, System Integration, which are currently implemented by Mozilla Firefox are not with Opera .

Context-menu –Right-clicking Opera Icon in Gnome Desktop– is expected to be exhibited according to system language currently in use, here Finnish for instance.

$ dnf -q repolist | grep opera
opera                                        Opera packages                6
$ dnf -q list installed opera-stable | sed -n '2p'
opera-stable.x86_64                 62.0.3331.99-0                 @@commandline

At last succeeded installation is relevant to be under a unique software repository, not two. Regards.

Version: 56.0.3051.31 – Feature request – Home page

The home page concept was so appropriate for modern use of browser, and since it is not implemented any more in Opera, it is missing. The icon associated to it was rather convenient to use; the Start Page –a useful feature too– icon is located where the Home Page icon used to be. The only good feature left, despite not related to the home page concept, that has somehow a similarity in spirit with that one, is illustrated by that unique option::

On startup | Select option Open a specific page or set of pages

RESTful online applications may use of many of the request methods which World Wide Web and HTTP are based on, while web browsers classically use at most GET., POST requests methods. In GET request, query string is sent as part of the URL. GET requests can be cached, bookmarked and remain in the browser history. The use of GET request is not an option when dealing with sensitive data. It is only used to request data, not modified it.

POST request sends data to a server in order to update/create a resource. POST request has similarities with GET request, except it contains a body. That data sent to the server is stored in the request body of the HTTP request. POST requests are not cached and cannot be bookmarked. They do not remain in the browser history.

POST is somehow safer than GET because the parameters are not stored in browser history or in web server logs and because data sent is not part of the URL.

Those for which true confidentiality comes with no compromise, search engines providing a cloud storage service regarding browser's settings is definitively not an option. The dully auto-stated, world's most private search engine has by default the right settings to deserve that appellation. Then POST method is coherently as default. Since any government surveillance programs that were begun with good intentions unaccountably have become tools for abuse, it even provides the ability to opt for the use of EU-servers, instead of US' ones, in order for EU users to avoid the mass Internet surveillance program "PRISM".
Despite the cookie StartPage sets to save settings is non-identifiable and therefore safe to accept, cookies in general may pose a threat to user's privacy.

For those users like me that do not accept cookies, an option is provided to generate an URL in an obfuscated form, (model: 'https://www.startpage.com/do/mypage.pl?prf=5ca7c2adc2e8c17819jk4eed4cf197ae'. Despite that generated URL can be set as homepage or used as bookmark, it cannot be yet as search engine in any web browsers, which counts Opera.

Though an URL in GET form, such as 'https://www.startpage.com/do/search?query=%s' , would be a valid one to be used for the addition of a search engine, but it still would use the GET method. In that context, would it be fair to request from Opera the implementation of a new design scheme that would allow a search engine involving such an URL relying on POST method to be set as the default one?

@jbrandon. An option titled 'Enable dark theme' has been made available –path: opera://settings/ , under category Basic, subcategory Appearance–. Yet targets to which that function applies are without doubt on purpose made restrictive as that observation cannot possibly be an issue. Those built-in pages Bookmarks, Personal News, History, Extensions, have been left in the UI team process out of consideration, and their readability illustrate still what an unfriendly eye-destructive over-lighted theme can be. Title 'Enable dark theme', comes along with no particular mention; therefore its application is meant to be global, while it currently applies only to the built-in page Settings.

Bright backgrounds are obviously well known to fill doctors' list of customers constantly full, as such backgrounds are indeed so eyes consuming which is no trivial case. Expectedly current request concerns the need for a solid dark color as an alternative option so that current reading won't be aggressive any more. That is only one of the so many ways to deserve a qualification closest to 'modern' regarding the very web browser Opera.

Hi. Only when the browser is opened in Private mode and regarding the LastPass extension in Extensions interface the option Allow in private mode is selected, a systematic crash occurs when clicking the LastPass’ icon in the login field. The browser is unable to recover from such a consecutive crash.

The Private Window mode keeps tracks of history regarding the managed extensions while it is expected not to do so. While checking for testing purpose the Clear browsing data… section, History appears to be empty as it should when dealing with web pages but not regarding the managed extensions. Wouldn't it be preferable to make the Private Window mode working globally by covering extensions as well?

Even in Private Window mode, after having logged out from an account and then having refreshed the web page (Issue currently occurred with the Google GMAIL service), had no effect on the login display as the page kept displaying the previous login name. Issue could only be avoided by shutting down the current tab and reopening a new one with the same login page.

Official on-line available information lacks of transparency regarding the free, unlimited, and with no subscription built-in VPN service related possible internal vulnerabilities. Would Opera be kind enough to inform transparently and in a clearly form its on-line documentation regarding the present topic?

As mentioned on Opera's web site, this service in Opera browser is provided by SurfEasy Inc., an Opera company based in Canada. By offering such a legitimate service aimed to enhance privacy and even for free of charge, it rises concerns regarding the essentially privacy, about leakages which indeed do occur behind VPN services (paid or not).

Currently a growing range of techniques like fingerprinting detection attempts through Canvas elements, like Canvas font access, audio (via the AudioContext API), via the WebGL API), via the Battery API), device enumeration (via the WebRTC API), gamepad enumeration (via the Gamepad API), WebVR enumeration (via the WebVR API), or through calculating Client’s element rectangles. decrease instantaneously the very effectiveness of VPN services.

However, protection against those attempts requires unfortunately for now a third-party add-on, that may not be trust-worth. The fact that only one add-on of that nature is currently present for download in the add-on collection available in Opera, may not be a surprise for the few who were aware of the challenging situation in protecting even with VPN.

Does Opera use for tunneling and data encapsulation the PPTP protocol, which is fundamentally insecure due to using short length encryption keys and password hashes that can be cracked by a skilled individual or the L2TP/IPSec protocol, which has already been tampered successfully by the NSA. In case Opera uses a more secure protocol, may the traffic remain vulnerable because of the use of insecure ciphers?

Does the VPN service require use of Perfect Forward Secrecy ciphers, so VPN network traffic can not be saved, and subsequently decrypted later if the encryption keys or algorithms have been compromised?

At last, while VPN services usually do protect web traffic, many do not or loosely, protect DNS lookups, meaning that user’s browsing history can still be reconstructed from DNS lookups. How does Opera protect DNS lookups from DNS leakage if it even does?