Firefox 51.0.1 does not display pages/shows blank pages.

Hi, could you please tell me what addons you have installed? Can you access about:support? (and if you can, could you please copy the contents in to this bug report). Could you also please try launching Firefox from a terminal with the "-safe-mode" option?

скажите, "MOZ_FORCE_DISABLE_E10S=1 firefox" пожалуиста

Chris Coulson, в safe-mode тоже не работает.
Seth Arnold, где "сказать" "MOZ_FORCE_DISABLE_E10S=1 firefox"? Вы считаете меня телепатом? И как много таких телепатов среди вашего круга общения?

The same problem here on Lubuntu 16.04.1 amd64, starting in safe mode does not cure it.

lsb_release -rd
Description: Ubuntu 16.04.1 LTS
Release: 16.04

apt-cache policy firefox
firefox:
  Telepítve: 51.0.1+build2-0ubuntu0.16.04.1
  Jelölt: 51.0.1+build2-0ubuntu0.16.04.1
  Verziótáblázat:
 *** 51.0.1+build2-0ubuntu0.16.04.1 500
        500 http://archive.ubuntu.com/ubuntu xenial-security/main amd64 Packages
        100 /var/lib/dpkg/status
     50.1.0+build2-0ubuntu0.16.04.1 500
        500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
     45.0.2+build1-0ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

I cannot attach the output of the 'ubuntu-bug firefox' file.

I think there is some conflict with AppArmor because set the AppArmor profile of the Firefox in complain mode Firefox works well, but set it in enforced mode it cannot write into 'owner @{HOME}/.{firefox,mozilla}' folder. My total paragraph for 'owner @{HOME}/.{firefox,mozilla}':

# per-user firefox configuration
  owner @{HOME}/.{firefox,mozilla}/ rw,
  owner @{HOME}/.{firefox,mozilla}/** rw,
  owner @{HOME}/.{firefox,mozilla}/**/*.{db,parentlock,sqlite}* k,
  owner @{HOME}/.{firefox,mozilla}/plugins/** rm,
  owner @{HOME}/.{firefox,mozilla}/**/plugins/** rm,
  owner @{HOME}/.gnome2/firefox*-bin-* rw,

With the pre-51.0.1+build2-0ubuntu0.16.04.1 FF it worked fine.

Agreed. I have the issue as well and running:

  sudo aa-complain /etc/apparmor.d/usr.bin.firefox

fixes it.

Sziráki Tamás, James E. Blair, не держите нас за идиотов. Вы предлагаете отключить и дать расширенные права Firefox в Apparmor. Может быть вы хотите предложить вообще на хер выкинуть Apparmor? Я, например, не идиот. Давайте исправляйте ваше последнее обновление Firefox или пишите разработчикам Firefox, пусть исправляют свою вирусную поделку.
Ещё раз повторяю: "Не держите нас за идиотов!" Так понятно вам? Или вам по-русски сказать?

Никитушкин Андрей (anikitushkin), le style, c'est l'homme.

At every start Firefox cannot find the profile folder, so creates a new one, but is unable to write into it.

kernel: [42201.498741] audit: type=1400 audit(1485640707.475:7982846): apparmor="ALLOWED" operation="mknod" profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/dev/shm/org.chromium.msCy8J" pid=26303 comm=57656220436F6E74656E74 requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
kernel: [42201.498756] audit: type=1400 audit(1485640707.475:7982847): apparmor="ALLOWED" operation="open" profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/dev/shm/org.chromium.msCy8J" pid=26303 comm=57656220436F6E74656E74 requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000
kernel: [42201.498789] audit: type=1400 audit(1485640707.475:7982848): apparmor="ALLOWED" operation="unlink" profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/dev/shm/org.chromium.msCy8J" pid=26303 comm=57656220436F6E74656E74 requested_mask="d" denied_mask="d" fsuid=1000 ouid=1000
kernel: [42201.498797] audit: type=1400 audit(1485640707.475:7982849): apparmor="ALLOWED" operation="truncate" profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/dev/shm/org.chromium.msCy8J" pid=26303 comm=57656220436F6E74656E74 requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000

Seems like this needs to be fixed :)

This bug is in fact duplicate of #1627239
But since FF51, E10S is enabled by default, so more and more people are hitting this bug now ...

Time to fix :)

"/dev/shm/org.chromium.* rw,"

And we're set!

A patch which might fix this issue, too, is available at 1659988.

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1659988

Everyone affected, please give it a try and report back.

Related and/or duplicate: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1627239

Thomas Mayer (thomas303), проверяйте сами, придурки, нам надо чтобы был патч, который данную проблему исправляет. Школьники, мля! Непрофессионально!

Google translate translates comment #15 to "Thomas Mayer (thomas303), check yourself, assholes, we need to was a patch that fixes the problem. Students, blah! Unprofessional!"

Not the feedback I wish to hear for voluntary work.

Не обратной связи я хотел бы услышать о добровольной работе.

I'm seeing this for the first time with my update yesterday, 28 Jan 2017 23:00 PST, pushed out with standard Ubuntu updates for Ubuntu 12.04.5 LTS.

I can see the default entrance page, the preferences page, and about:config. But I cannot see any html pages. However, html <title> does appear to render in the frame title bar, and rolling the mouse seems to show urls behind links in the normal way at the lower left corner of the frame.

I'm not building firefox from source.

Is there a fix in about:config?

Otherwise could you push out a fixed build for the dpkg package "firefox" within a few days?

Thanks.

@wfhammond It is not necessary to build FF to test my patch from https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1659988

The patch patches a config file only (an apparmor profile, to be precise). Can be done in a text editor, too. With the patch applied, FF 51.0.1 should work again.

Thomas Mayer (thomas303), после добавления owner /dev/shm/org.chromium.* rw в патч и в профиль Apparmor для Firefox Firefox заработал. Спасибо. Но это костыль, обновления по данной проблеме как не было, так и нет. Сотрудники Canonical - школьники, которые не проверяют программное обеспечение.

Google translate translates comment 19 to "Thomas Mayer (thomas303), after adding the owner /dev/shm/org.chromium.* rw in the patch and Apparmor profile for Firefox Firefox earned. Thank you. But this is a crutch, an update on the issue as there was no and no. Employees of Canonical - Students who do not test software security."

@anikitushkin

There's no reason to believe that the package maintainers lowered security by NOT applying necessary changes to the new requirements of FF 49+. It's rather the other way round: Not widening the apparmor profile to the new requirements of FF is pretty conservative in terms of security. It's just that apparmor blocking requirements of FF renders it broken now - be it because of that conservative approach or because of not testing at all. I agree, that should and could have been tested in the first place, namely before releasing new major versions of FF.

Of course, the FF package needs to be updated to fix this issue for average users. I'm not the maintainer of the FF package, which basically means that I don't have permission to do that myself.

I guess that you can speed up Canonical's integration of the patch into the official package by testing it and reporting back if it works. The reason for that is that package maintainers hopefully become more confident that the patch really fixes exactly this issue as long as multiple users report exactly that, independently of each other.

@wfhammond My patch is tested by myself against 16.04 only. It's not tested against 12.04 or 14.04. I'm not sure how that works out, would be great if you can test it against 12.04, too.

@chrisccoulson I can confirm that the problem can be reproduced with all FF extensions/plugins disabled.

Since FF 51.0.1, enabling or disabling the extension "ubuntu modifications" does not fix this issue any more (to my knowledge, that was the case up until FF 49 and 50).

@thomas303: E10S (which triggers this issue) was only enabled in FF 51 when using non-whitelisted plugins.
So this might be the difference between previous versions. Where disabling all the plugins enabled E10S, and thus caused the issue.

@dupondje Not exactly: In my case FF was broken directly after the update to 51.0.1, without any further change, including configuration and extensions/plugins.

And yes, by its nature, it's a regression. Not in FF upstream, but in the ubuntu package (apparmor profile).

The problem itself could be older: I have seen this issue earlier (FF49/50), when playing around with E10S manually (in about:config). Up until FF50 that could be worked around, but my workaround (installing extension "ubuntu modifications") does not work any more for 51.0.1.

@thomas303

I tried your patch but it does not work, after reloading apparmor or rebooting.

But I found out that my browser profiles with the addon "Screengrab (fix version)" 0.99.97c are still working. How is that possible?

@asgard2 Which version of the patch are you using? Which version of ubuntu are you using? The patch is against 16.04, whereas it's unknown what it does to 12.04/14.04.

Please try again with "VERSION 6" of the patched full version, as shown in

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1659988/comments/21

If an extension is _not_ compatible to E10S, it is possible that installing such an extension disables this feature. As a result, your browser eventually runs again.

@thomas303

hm, its not working here with version 6 and lubuntu 16.04

@thomas303

yes, with Screengrab e10s is disabled.

What happens if you do a

cd /etc/apparmor.d/disable
ln -s ./../usr.bin.firefox
ln -s ./../usr.bin.firefox_patched

?

This is just to test if your problem is at least _related_ to apparmor. Should be undone after the test as it disables the apparmor profile for firefox (temporarily weakens security).

@asgard2 ...followed by a

service apparmor reload

For a long while, I've been using this local include file with success on Xenial 16.04. To make use of it, download the "local/usr.bin.firefox" file to /tmp and do:

sudo cp /tmp/usr.bin.firefox /etc/apparmor.d/local/usr.bin.firefox
sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.bin.firefox

Then restart your Firefox.

@sdeziel Is this somehow related to the E10S issues? Have you been faced with these issues and do you claim that your apparmor profile fixes them?

@Thomas, some of the rules are related to E10S but a lot predate it. I noticed you opened quite a few bugs with regards to Firefox's profile, most of those would have been fixed had one included my local/usr.bin.firefox rules into the main profile as shipped by the package.

I try to keep the local rules up to date in LP: #1533232, hoping that someone will include them in the main profile someday :)

@sdeziel That was intentional: How should someone keep track of what your profile fixes if there's no ticket for each rule?

How should a maintainer decide if that should be merged?

Please don't duplicate specific tickets to an unspecific ticket. That just confuses - at least me.

On 2017-01-31 01:24 PM, Thomas Mayer wrote:
> @sdeziel That was intentional: How should someone keep track of what
> your profile fixes if there's no ticket for each rule?

I see your point.

> How should a maintainer decide if that should be merged?

The problem is that nobody seems to care about Firefox's Apparmor
profile because it's disabled by default. I don't think that having many
small LPs will increase the likeliness of someone picking up the
individual changes one at the time and get them through SRU. I was
aiming for inclusion in the dev version of Ubuntu, in one batch.

> Please don't duplicate specific tickets to an unspecific ticket. That
> just confuses - at least me.

Alright, I'll stop. There is no point in arguing here since we both
pursue the same goal: have good Apparmor support for Firefox

Regards,
Simon

@sdeziel Exactly. To be honest, I have seen your ticket and effort you did. But I could not figure out what your version of the profile intended to fix, because that is not documented anywhere.

That could also be the reason why nobody merged it within more than a year. There's nobody to blaim for that, in my opinion. A maintainer maintaining stable releases should at least know what a change is supposed to fix.

My approach in https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1659988 documents each step and each issue which is supposed to be fixed.

That approach also is supposed to be minimal-invasive: Not more than documented, no refactoring.

I even would not argue that my patch somehow is better. Eventually, you fixed a lot more. I just don't know what it does because it's not documented.

Let's hope for the best, may at least one of the patches be merged. Personally, I don't care which, as long as things are finally fixed.

@thomas303

The problem is still there if I only deactivate the firefox profile.

Maybe it is related to another apparmor profile, the apparmor-profiles package is installed.

@sdeziel In the long run, I think that mozilla should provide such a profile, now that FF's dependencies can change at any time, whereas distros must roll it out quickly because of security fixes.

Why should all the distros do that independently? There's a lot of redundancy which could be allocated elsewhere.

On 2017-01-31 02:20 PM, Thomas Mayer wrote:
> Why should all the distros do that independently? There's a lot of
> redundancy which could be allocated elsewhere.

Indeed but cross-distro compatibility is profiles as not every
distro/release have the same feature set. For example, not all supported
version of Ubuntu have dbus/ptrace mitigation support. Recently, Debian
also enabled Apparmor but with a smaller feature set than the latest Ubuntu.

That said, I will try to reach out to the Ubuntu maintainer to at least
improve that. If we get somewhere maybe Debian or upstream would be next.

Ugly as it is, but mozilla could also maintain profiles for different feature sets, or distros, respectively.

But there's more: Different versions of FF with different requirements. The only right place to keep track of that is in the source repo of FF. Even if Mozilla does not maintain it distro specific, it would allow distros to keep track of necessary changes, at least. The latter approach could at least serve as a reference.

The current situation is at least unsatisfying: Disabling the profile because it's unmaintainable.

@kamp000x If you have the same problem with the apparmor profile disabled, then your problem is not related to apparmor. Then you have a different problem. Maybe your drivers are not compatible.

From my side, I can say that, if the issue is related to apparmor, the E10S issues disappear as soon as FF's apparmor profile is disabled. I've seen/tested that myself.

If your problem is not apparmor related, my patch won't fix it.

@thomas303

If I disable apparmor, the problem is gone, so it is related to apparmor.

@thomas303
with disable I mean:
service apparmor teardown

On 2017-01-31 02:51 PM, Thomas Mayer wrote:
> Ugly as it is, but mozilla could also maintain profiles for different
> feature sets, or distros, respectively.
>
> But there's more: Different versions of FF with different requirements.
> The only right place to keep track of that is in the source repo of FF.
> Even if Mozilla does not maintain it distro specific, it would allow
> distros to keep track of necessary changes, at least. The latter
> approach could at least serve as a reference.
>
> The current situation is at least unsatisfying: Disabling the profile
> because it's unmaintainable.

If you have the time, I would encourage you keep the profile enabled and
collect all the missing rules in a local/ profile whenever possible (not
possible for the lsb_release subprofile). If you desire, you could start
with what's in LP: #1533232 as I spend a lot of time collecting those
dbus and other rules. That's what I'd like to bring to the maintainer
when time permits.

@sdeziel feel free to to take rules from bug #1659988 patch version 6. Some are still missing, e.g. python 3.5 support.

@thomas303
It was a local apparmor config issue..., your patch (version 6) worked, thanks!

Any chance we can get this moved out of proposed and approved for zesty?

This bug was fixed in the package firefox - 51.0.1+build2-0ubuntu0.12.04.2

---------------
firefox (51.0.1+build2-0ubuntu0.12.04.2) precise-security; urgency=medium

  * Fix LP: #1659922 - Fix Apparmor denials triggered by shared memory usage
    when e10s is enabled

 -- Chris Coulson <email address hidden> Wed, 01 Feb 2017 17:21:28 +0000

This bug was fixed in the package firefox - 51.0.1+build2-0ubuntu0.16.10.2

---------------
firefox (51.0.1+build2-0ubuntu0.16.10.2) yakkety-security; urgency=medium

  * Fix LP: #1659922 - Fix Apparmor denials triggered by shared memory usage
    when e10s is enabled

 -- Chris Coulson <email address hidden> Wed, 01 Feb 2017 16:49:07 +0000

This bug was fixed in the package firefox - 51.0.1+build2-0ubuntu0.14.04.2

---------------
firefox (51.0.1+build2-0ubuntu0.14.04.2) trusty-security; urgency=medium

  * Fix LP: #1659922 - Fix Apparmor denials triggered by shared memory usage
    when e10s is enabled

 -- Chris Coulson <email address hidden> Wed, 01 Feb 2017 17:20:44 +0000

Hi. I've had this problem since November (see: <https://lists.ubuntu.com/archives/apparmor/2016-November/010274.html>) And it turned out that I had to add to the Firefox profile a couple of rules (These problems occured after Firefox update to the 49/50 versions.) So, I added:

@{PROC}/[0-9]*/net/arp r,
owner /run/shm/org.chromium.* rw,

(see: <https://lists.ubuntu.com/archives/apparmor/2017-January/010445.html>)
owner @{PROC}/[0-9]*/task/ r,
owner @{PROC}/[0-9]*/task/* r,

(see: <https://lists.ubuntu.com/archives/apparmor/2017-January/010496.html>, <https://lists.ubuntu.com/archives/apparmor/2017-January/010505.html>)
#include <abstractions/nvidia>

Everything after Firefox update and e10s enabled. Also, recently appeared problem with "lsb_released" DENIED message (in the log files such as, for example, /var/log/kern.log). After every first Firefox start, there was an entry such as:

[...] audit(1486317534.042:95): apparmor="DENIED" operation="exec" parent=4197 profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/usr/bin/lsb_release" pid=4198 comm="firefox" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

I've had to add "lsb_release" child profile to the Firefox profile (see <https://lists.ubuntu.com/archives/apparmor/2017-January/010508.html> and <https://lists.ubuntu.com/archives/apparmor/2017-February/010523.html>) suggested by Mr Seth Arnold (many thanks!). After this step, mentioned DENIED entry no longer appears.

Anyway, after Firefox update (ver. 49/50) and enabling e10s I've had to make some changes in an official Firefox profile etc. Everything happened on the 12.04 LTS Release.

Thanks.

Please merge all the other duplicate bugs into this one.

A new build of Firefox 51.0.1 was pushed out as a standard update for the elderly Ubuntu 12.04.5 LTS. The display problem is no longer present. That was my complaint. I'm not in a position to say whether it is suitably armored. Thanks to whoever fixed it.

Hi William. I've had this problem last year (see: <https://lists.ubuntu.com/archives/apparmor/2016-November/010274.html>) and adding one rule - according to logs messages - fixed this issue. It was:

owner /{dev,run}/shm/org.chromium.* rwk,

A rule, which was added by the latest Firefox update/build (mentioned by You). So, honestly I have not nothing to do - I just have kept the current version. During update there was a message about changes made by the maintainer etc., and I had to decide what to do. Of course I've used "N" or "O" option. That's all. Release: 12.04 LTS.

Best regards.

If this has been approved for stable series, any reason why it's being held up in proposed for zesty?

Is there a bug # for this problem as observed in Firefox Quantum 57.0 (64-bit) ?

Hi!
I not know. I current not use Firefox. You can debug this audit problem
with Firefox with use reading messages "audit:" from standard syslog
file in /var/log/

On 30.11.2017 00:18, James Waldby wrote:
> Is there a bug # for this problem as observed in Firefox Quantum 57.0
> (64-bit) ?
>