7 ms·

> So how does a browser that should provide a fully integrated experience on a Chromebook do the same? That browser has to communicate with the operating system

> So how does a browser that should provide a fully integrated experience on a Chromebook do the same? That browser has to communicate with the operating system which provides some of that functionality. Google has had to create much of that functionality for an external, or non-integrated browser over the past three years. Does this also mean it would be feasible to port Firefox and have it be the native and default browser on ChromeOS with the same OS integration as Chrome? That would be pretty cool. (I'm aware that there are ways to run Firefox on ChromeOS today).

nateb2022 3y ago
It's already possible to run Firefox on chromeOS, see https://support.mozilla.org/en-US/kb/run-firefox-chromeos https://support.mozilla.org/en-US/kb/run-firefox-chromeos > with the same OS integration as Chrome? This, however, would require a lot of changes in chromeOS itself that Google won't do. It would be possible in a fork of chromeOS, though that would be a lot of work and would involve adding several APIs to Firefox that chromeOS relies on.
- mdwalters 3y ago
  > It's already possible to run Firefox on ChromeOS True, but what about running Firefox natively, without the sandbox?
  - PlutoIsAPlanet 3y ago
    You mean running without the VM? Sandbox doesn’t mean non native, Chrome itself is arguably running in a sandbox.
- modeless 3y ago
  As my original comment said very clearly, I am aware that you can run Firefox on ChromeOS today. That's not what I'm talking about. > This, however, would require a lot of changes in chromeOS itself that Google won't do Lacros is exactly those changes, though. That's my point. Google already did the work to add all the integration points you need to integrate a browser into the OS.
  - nateb2022 3y ago
    > Lacros is exactly those changes, though. Lacros doesn't give Firefox the APIs that ChromeOS utilizes from Chrome that Firefox lacks. E.g. web battery API, web bluetooth API, web USB API, etc. These are the changes I'm referring to. That's my point. That's what I mean when I said: > [this] would involve adding several APIs to Firefox that chromeOS relies on.
- adfgionoi 3y ago
  It's possible to run a virtual machine on ChromeOS, and within that virtual machine it's possible to run Firefox. This is not the same as running Firefox. A ton of things (like drag and drop, video calls, and some aspects of rendering) are subtly broken. There is no hardware acceleration. Performance is atrocious; expect 15 FPS video maximum. There is a separation between Firefox and the rest of the system, with two filesystems and links opening in the wrong software. Accessing any hardware peripherals such as security keys, cameras, or microphones is unreliable at best. To anyone who has never had the misfortune of using a Chromebook: this stuff works terribly. Don't listen to anyone telling you otherwise. (I think it's actually a container rather than a virtual machine.)
  - bpye 3y ago
    It is a VM though with a light weight VMM > crosvm is a custom virtual machine monitor that takes care of managing KVM, the guest VM, and facilitating the low-level (virtio-based) communication. However the actual application is run within a container inside that VM - if I understand correctly. https://chromium.googlesource.com/chromiumos/docs/+/HEAD/containers_and_vms.md#Overview https://chromium.googlesource.com/chromiumos/docs/+/HEAD/con...
- NoZebra120vClip 3y ago
  Firefox had an OS, and it was rebranded to KaiOS, which is still extant and active today. FirefoxOS/KaiOS, however, is targeted only for feature phones, and therefore, resource-constrained systems. I did enjoy one such phone, and it had a fairly decent browser, though I can't say that it had any Firefox-like features that I could identify, because it was so incredibly minimal.
  - qingcharles 3y ago
    The browser might be OK. The rest of the OS is absolute hell. Missed opportunity.
- insanitybit 3y ago
  > would require a lot of changes in chromeOS itself that Google won't do. literally the entire linked article is about them doing this work
  - nateb2022 3y ago
    > literally the entire linked article is about them doing this work Lacros doesn't give Firefox the APIs that ChromeOS utilizes from Chrome that Firefox lacks. E.g. web battery API, web bluetooth API, web USB API, etc. These are the changes I'm referring to. That's my point. That's what I mean when I said: > [this] would involve adding several APIs to Firefox that chromeOS relies on.
insanitybit 3y ago
It does seem that way, at least assuming that the APIs are stable - and I assume they will be since the whole point is that both sides won't have to coordinate their releases.
- bagacrap 3y ago
  I suspect "stability" will look a lot different from Windows though. They won't be supporting old versions of the API for 30 years but maybe 3 months, since both browser and OS are still expected to be kept up to date for security reasons and supporting old versions of code is onerous. Edit: found this - > The API boundary initially will be semi-stable: it will tolerate 1-2 milestones of version skew. We may allow larger amounts of skew in the future. FF would have a hard time keeping up I think.
  - insanitybit 3y ago
    I imagine that as things stabilize Firefox will be able to handle it. After all, it needs to be manageable by the Chrome team too. Unless the Chrome team is given hidden notice about API changes well in advance, which seems sort of unlikely.
    - bagacrap 3y ago
      Every time an API changes, whether by a little or a lot, the FF team has about 2 months to deal with it. You think that's going to happen? There's just a squad of engineers sitting around doing nothing at all times, waiting for the next emergency to drop? The amount of resources moz would need to allocate to this project (which has little purpose given alternatives) would be prohibitive.
      - insanitybit 3y ago
        > Every time an API changes, whether by a little or a lot, the FF team has about 2 months to deal with it. You think that's going to happen? Yes? That doesn't sound that hard. Browser release on a tighter cadence than that. And it's just starting off at 2 months. > There's just a squad of engineers sitting around doing nothing at all times, waiting for the next emergency to drop? Uh... no? They would be normal FF engineers who would sometimes get a release ticket that says they need to update to a new API... > The amount of resources moz would need to allocate to this project (which has little purpose given alternatives) would be prohibitive. Totally disagree. This sounds like something engineers could take as a chore.

nateb2022 3y ago

It's already possible to run Firefox on chromeOS, see https://support.mozilla.org/en-US/kb/run-firefox-chromeos https://support.mozilla.org/en-US/kb/run-firefox-chromeos > with the same OS integration as Chrome? This, however, would require a lot of changes in chromeOS itself that Google won't do. It would be possible in a fork of chromeOS, though that would be a lot of work and would involve adding several APIs to Firefox that chromeOS relies on.

mdwalters 3y ago
> It's already possible to run Firefox on ChromeOS True, but what about running Firefox natively, without the sandbox?
- PlutoIsAPlanet 3y ago
  You mean running without the VM? Sandbox doesn’t mean non native, Chrome itself is arguably running in a sandbox.
modeless 3y ago
As my original comment said very clearly, I am aware that you can run Firefox on ChromeOS today. That's not what I'm talking about. > This, however, would require a lot of changes in chromeOS itself that Google won't do Lacros is exactly those changes, though. That's my point. Google already did the work to add all the integration points you need to integrate a browser into the OS.
- nateb2022 3y ago
  > Lacros is exactly those changes, though. Lacros doesn't give Firefox the APIs that ChromeOS utilizes from Chrome that Firefox lacks. E.g. web battery API, web bluetooth API, web USB API, etc. These are the changes I'm referring to. That's my point. That's what I mean when I said: > [this] would involve adding several APIs to Firefox that chromeOS relies on.
adfgionoi 3y ago
It's possible to run a virtual machine on ChromeOS, and within that virtual machine it's possible to run Firefox. This is not the same as running Firefox. A ton of things (like drag and drop, video calls, and some aspects of rendering) are subtly broken. There is no hardware acceleration. Performance is atrocious; expect 15 FPS video maximum. There is a separation between Firefox and the rest of the system, with two filesystems and links opening in the wrong software. Accessing any hardware peripherals such as security keys, cameras, or microphones is unreliable at best. To anyone who has never had the misfortune of using a Chromebook: this stuff works terribly. Don't listen to anyone telling you otherwise. (I think it's actually a container rather than a virtual machine.)
- bpye 3y ago
  It is a VM though with a light weight VMM > crosvm is a custom virtual machine monitor that takes care of managing KVM, the guest VM, and facilitating the low-level (virtio-based) communication. However the actual application is run within a container inside that VM - if I understand correctly. https://chromium.googlesource.com/chromiumos/docs/+/HEAD/containers_and_vms.md#Overview https://chromium.googlesource.com/chromiumos/docs/+/HEAD/con...
NoZebra120vClip 3y ago
Firefox had an OS, and it was rebranded to KaiOS, which is still extant and active today. FirefoxOS/KaiOS, however, is targeted only for feature phones, and therefore, resource-constrained systems. I did enjoy one such phone, and it had a fairly decent browser, though I can't say that it had any Firefox-like features that I could identify, because it was so incredibly minimal.
- qingcharles 3y ago
  The browser might be OK. The rest of the OS is absolute hell. Missed opportunity.
insanitybit 3y ago
> would require a lot of changes in chromeOS itself that Google won't do. literally the entire linked article is about them doing this work
- nateb2022 3y ago
  > literally the entire linked article is about them doing this work Lacros doesn't give Firefox the APIs that ChromeOS utilizes from Chrome that Firefox lacks. E.g. web battery API, web bluetooth API, web USB API, etc. These are the changes I'm referring to. That's my point. That's what I mean when I said: > [this] would involve adding several APIs to Firefox that chromeOS relies on.

insanitybit 3y ago

It does seem that way, at least assuming that the APIs are stable - and I assume they will be since the whole point is that both sides won't have to coordinate their releases.

bagacrap 3y ago
I suspect "stability" will look a lot different from Windows though. They won't be supporting old versions of the API for 30 years but maybe 3 months, since both browser and OS are still expected to be kept up to date for security reasons and supporting old versions of code is onerous. Edit: found this - > The API boundary initially will be semi-stable: it will tolerate 1-2 milestones of version skew. We may allow larger amounts of skew in the future. FF would have a hard time keeping up I think.
- insanitybit 3y ago
  I imagine that as things stabilize Firefox will be able to handle it. After all, it needs to be manageable by the Chrome team too. Unless the Chrome team is given hidden notice about API changes well in advance, which seems sort of unlikely.
  - bagacrap 3y ago
    Every time an API changes, whether by a little or a lot, the FF team has about 2 months to deal with it. You think that's going to happen? There's just a squad of engineers sitting around doing nothing at all times, waiting for the next emergency to drop? The amount of resources moz would need to allocate to this project (which has little purpose given alternatives) would be prohibitive.
    - insanitybit 3y ago
      > Every time an API changes, whether by a little or a lot, the FF team has about 2 months to deal with it. You think that's going to happen? Yes? That doesn't sound that hard. Browser release on a tighter cadence than that. And it's just starting off at 2 months. > There's just a squad of engineers sitting around doing nothing at all times, waiting for the next emergency to drop? Uh... no? They would be normal FF engineers who would sometimes get a release ticket that says they need to update to a new API... > The amount of resources moz would need to allocate to this project (which has little purpose given alternatives) would be prohibitive. Totally disagree. This sounds like something engineers could take as a chore.