Open Bug 1930592 Opened 28 days ago Updated 6 days ago

Firefox 132 generates empty HTTP MOZ log on Ubuntu

Categories

(Core :: XPCOM, defect)

Firefox 132
defect

Tracking

()

UNCONFIRMED

People

(Reporter: peter, Unassigned, NeedInfo)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.1 Safari/605.1.15

Steps to reproduce:

Using Browsertime and the switch --firefox.collectMozLog to generate a MOZ HTTP log generates empty files (0 bytes) on Linux. Doing the same on Mac OS works (the files contains the requests). In the background the env variable MOZ_LOG is set to timestamp,nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5

The issue is tracked in https://github.com/sitespeedio/browsertime/issues/2202 but it looks like the problem is Firefox on Linux.

The net logs is needed so we can investigate the regression in https://bugzilla.mozilla.org/show_bug.cgi?id=1930110

Either this has never worked on Linux or its something that's been introduced.

Do you have any tests where you verify that the logs is created with content for Linux?

The Bugbug bot thinks this bug should belong to the 'Toolkit::UI Widgets' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → UI Widgets
Product: Firefox → Toolkit

We're not totally sure where this belongs, but it's definitely not a Toolkit/UI Widgets issue. Tracking down where these env vars are getting defined and used it looks like Core::Networking or Core::XPCOM folks might have more of a clue.

Component: UI Widgets → Networking
Product: Toolkit → Core
Component: Networking → XPCOM

The severity field is not set for this bug.
:nika, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(nika)

Given that you're using Ubuntu, is it possible you're accidentally using a Snap build? Or a regression caused by their AppArmor rules? (The latter only on 24.04 tho)

Is dom.ipc.forkserver.enable=true in your environment? Does flipping it help?

It appears that browsertime should be setting MOZ_LOG and MOZ_LOG_FILE (https://github.com/sitespeedio/browsertime/blob/23c33e64540589fc0f9136283e7a6aa7e4a3806d/lib/firefox/webdriver/builder.js#L63-L66). I'm not aware of any particular issue with MOZ_LOG on Android right now, beyond the potential for some kind of sandboxing issue where the specific sandbox is bloking writes to the log file. In my local builds I don't have any issue using MOZ_LOG and MOZ_LOG_FILE.

Is there any chance you're using an e.g. flatpak installation of Firefox for running these tests which might be adding additional sandboxing?

When I run locally some of the files with the specification you wrote are empty, but I believe that's because they correspond to processes which don't emit any of those logs. The main application and content process logs appear to have content like I would expect them to.

Leaving a ni? to get some more information about the configuration you're running the tests under so we can better understand the potential sandboxing issues.

Flags: needinfo?(nika) → needinfo?(peter)

Might be useful to mozregression it?

You need to log in before you can comment on or make changes to this bug.