If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Wayland support would be really great... it is time that Mozilla progresses on Linux! The Wayland port is available, it should be merged so that we can start testing.
I've seen a lot of activity in the Wayland-related bugs on Bugzilla recently, so I'm hoping we will see official support in 59.
CSD should land in 59 too.
It does provide a snappier experience. But I really miss my old setup around TST. Any suggestions on how to replace BarTabHeavy's "unload tab" feature? Also, ticket #1332447 is a real downer.
I've seen a lot of activity in the Wayland-related bugs on Bugzilla recently, so I'm hoping we will see official support in 59.
CSD should land in 59 too.
i wouldn't expect it before 60. And hopefully all the other features missing (layers acceleration on by default, HW video accel etc) would make some progress.
The inablity to use Canvasblocker would force me to run run all browsers in a VM pretending to be a default (except for remaining browser extensions) Linux Mint (or whatever distro is most popular) install on whatever computer was the highest selling model of the past year.
CanvasBlocker is a WebExtension since October 6th with version 0.4.0.
Hey, lets break old addons with that multiprocess thing(?), then lets break them again by moving to a whole new API. And lets remove the old API before we implement the replacements!
It was announced in Aug 2015 they would be switching to the webextention api.
If the extention makers decided not to update over 2 years 2 months... -_O_-
It was announced in Aug 2015 they would be switching to the webextention api.
If the extention makers decided not to update over 2 years 2 months... -_O_-
And Nov 2016 Mozilla themselves said that they still need to implement APIs: "Throughout the year we’ll expand the set of APIs available" (https://blog.mozilla.org/addons/2016...d-ons-in-2017/) Hard to update to something that didn't exist yet.
First, it demands that Rust and Cargo be very up to date. And woe to anyone who tries to compile Quantum with the git version of Rust: the process will throw out 19 (i counted) errors that must be manually patched.
Then, it needs an up-to-date LLVM and Clang to build the Stylo component.
And even when Quantum successfully builds, the default sandbox level of 3 blocks linking to shared system ffmpeg libraries, so no h264 or mp3 playback inbrowser. I managed to restore Facebook video playback by changing the sandbox level to 1.
Last edited by Sonadow; 15 November 2017, 07:00 AM.
Three years is plenty times. Some API aren't handled mainly due to security concern and some functionalities will be resorted once a proper solution is found. Rome
It was announced in Aug 2015 they would be switching to the webextention api.
If the extention makers decided not to update over 2 years 2 months... -_O_-
And Nov 2016 Mozilla themselves said that they still need to implement APIs: "Throughout the year we’ll expand the set of APIs available" (https://blog.mozilla.org/addons/2016...d-ons-in-2017/) Hard to update to something that didn't exist yet.
Actually, the first stable version of WebExtension was released with Firefox 48 (2016-08-02).[1]
The announcement for the deprecation was done in the blogpost posted in the above quote 2016-11-23.[2]
This means that the deprecation has been decided and executed in one year (1Y).
It's insanely short timeframe for rewriting and testing anything complex.
As their mix of languages and build glue gets more complex it becomes harder to actually get the source build. The last I could build from source was 55, which was already a pains due to the complex crap that is the Rust Cargo module system. Since 56 and still in 57 I get even more obscure new build failures :-/ http://t2sde.org/packages/firefox.html
if people can not even get to build it, how should people even review or possibility contribute back to the source?
As their mix of languages and build glue gets more complex it becomes harder to actually get the source build. The last I could build from source was 55, which was already a pains due to the complex crap that is the Rust Cargo module system. Since 56 and still in 57 I get even more obscure new build failures :-/ http://t2sde.org/packages/firefox.html
if people can not even get to build it, how should people even review or possibility contribute back to the source?
Is it really that complicated? I only had a few problems, namely:
1) Up to date Rust and Cargo required. Do not use Rust from the current Git if you want to avoid a lot of pain later on (speaking from experience).
2) Semi up-to-date LLVM required. You are good to go with LLVM v4 and higher
3) Semi up-to-date Clang required. You are good to go with LLVM v4 and higher with Clang built as part of the LLCM package.
With these requirements met (i built my own Rust, Cargo, LLVM and CLang using a mix of instructions from the Git readmes and the LFS site), I was able to build a working copy of Quantum.
Comment