682706 - When userContent.css is a symbolic link on Windows Vista or 7, firefox does not start up, seems to fall into a busy loop.

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect)

Description

[sh]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110811165603

Steps to reproduce:

I replaced Profiles/xxxx.default/chrome/userChrome.css with a symbolic link using mklink command on Windows Vista and 7.

How to reproduce this bug.

1. start cmd.exe as Admin
2. cd Profiles/xxxx.default/chrome/
3. mklink userContent.css C:\Users\username\userContent.css
4. start firefox

The version of Firefox is 

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0


Actual results:

Firefox does not start up, seems to fall into a busy loop.


Expected results:

Firefox start up normally.

Firefox 5 started up normally. Firefox 6 does not.

Comment 1

[Alice0775 White]

Confirmed on 
http://hg.mozilla.org/mozilla-central/rev/6c8a909977d3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110828 Firefox/9.0a1 ID:20110828030757

Firefox hangs up with CPU 100%/core.

Regression window(cached m-c hourly),
Works:
http://hg.mozilla.org/mozilla-central/rev/4fd08a1e0644
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110518 Firefox/6.0a1 ID:20110519025757
Hangs:
http://hg.mozilla.org/mozilla-central/rev/3cd7b0b686ff
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110519 Firefox/6.0a1 ID:20110519061001
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4fd08a1e0644&tochange=3cd7b0b686ff


Regression window(cached cedar hourly),
Works:
http://hg.mozilla.org/projects/cedar/rev/36bca8bcdb19
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110518 Firefox/6.0a1 ID:20110518042946
Hangs:
http://hg.mozilla.org/projects/cedar/rev/5f9f7a49e2e1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110518 Firefox/6.0a1 ID:20110518182630
Pushlog:
http://hg.mozilla.org/projects/cedar/pushloghtml?fromchange=36bca8bcdb19&tochange=5f9f7a49e2e1
Suspected:
Bug 541496 - Always provide strings rather than streams to the CSS parser

Comment 2

[Alice0775 White]

Attachment: WinDbg log

Comment 3

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Sh, I think I may have a solution; a build of Nightly with that change will come up in a couple of hours at <http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-70c3c0a8304a/try-win32/>. It would be great if you could test it to see if it fixes your problem. (I don't have access to Windows myself.)

Comment 4

[Alice0775 White]

(In reply to Ms2ger from comment #3)
> Sh, I think I may have a solution; a build of Nightly with that change will
> come up in a couple of hours at
> <http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> 70c3c0a8304a/try-win32/>. It would be great if you could test it to see if
> it fixes your problem. (I don't have access to Windows myself.)

compile failed.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ms2ger, see comment 4

Comment 6

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Thanks Boris.

Reporter, Alice, please see <https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-3763efcc1bcd/try-win32/>

Comment 7

[Alice0775 White]

(In reply to Ms2ger from comment #6)
> Thanks Boris.
> 
> Reporter, Alice, please see
> <https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> 3763efcc1bcd/try-win32/>

Nothing improved. the result is same as comment#0

Comment 8

[Boris Zbarsky [:bzbarsky]]

Alice0775, it looks like the call to Available() made in nsSyncLoadService::PushSyncStreamToListener keeps returning nonzero numbers.  Does the value returned there (15836 bytes) match the size of either your symlink file or the link target?  Can you maybe step into that call a few times and see what's going on in there?

Comment 9

[Alice0775 White]

(In reply to Boris Zbarsky (:bz) from comment #8)
> Alice0775, it looks like the call to Available() made in
> nsSyncLoadService::PushSyncStreamToListener keeps returning nonzero numbers.
> Does the value returned there (15836 bytes) match the size of either your
> symlink file or the link target? 

It is size of the target file.

> Can you maybe step into that call a few times 
How?

Comment 10

[Boris Zbarsky [:bzbarsky]]

I've never used windbg, so I don't know the details, unfortunately.  :(

The idea would be to put a breakpoint in nsFileInputStream::Available and see what values the NSPR call checkign the available bytes on the file descriptor returns... and how much that function gets called.

Comment 11

[Alice0775 White]

(In reply to Boris Zbarsky (:bz) from comment #10)
> I've never used windbg, so I don't know the details, unfortunately.  :(
> 
> The idea would be to put a breakpoint in nsFileInputStream::Available and
> see what values the NSPR call checkign the available bytes on the file
> descriptor returns... and how much that function gets called.

Sorry, I cannot...

Comment 12

[Boris Zbarsky [:bzbarsky]]

Ms2ger, do you have a Windows build env?  Or should I try to dust mine off?

Comment 13

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

I don't.

Comment 14

[Steven Penny]

As a workaround you can symlink the chrome folder instead.

cd Profiles/xxx.default
mklink chrome C:\Users\username\chrome

Comment 15

[Steven Penny]

Edit

mklink /d chrome C:\Users\username\chrome

Comment 16

[sebastien.barre]

I'll add that Firefox 51.0.1 (64 bits) on OSX will not load userContent.css if it is a symlink.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 18

[ISHIKAWA, Chiaki]

Well, I wanted to learn how linux version behaves if userChrome.css or userContent.css are symlinks.

Here is what I found.

To my surprise, they are NO longer read by firefox at all by default.

Then I realize that between the time the original post was made and now when the quantum version has been introduced, firefox made the reading of
user{Chrome|Content}.css an option behind config variable,
toolkit.legacyUserProfileCustomizations.stylesheets

Is this correct?

Anyway, I changed the above |toolkit.legacyUserProfileCustomizations.stylesheets| to true and then
firefox reads the file.
I verified it by using strace to monitor system calls. Presumably
|openat()| system calls are for reading them.

ishikawa@ip030:~/.mozilla/firefox/uwbw8ho5.default-release$ strace -o /tmp/t.out firefox 
[GFX1-]: glxtest: VA-API test failed: failed to initialise VAAPI connection.
ATTENTION: default value of option mesa_glthread overridden by environment.
[2022-10-04T09:16:44Z ERROR glean_core::metrics::ping] Invalid reason code startup for ping background-update
[2022-10-04T09:16:49Z ERROR viaduct::backend::ffi] Missing HTTP status
[2022-10-04T09:16:49Z ERROR viaduct::backend::ffi] Missing HTTP status
ishikawa@ip030:~/.mozilla/firefox/uwbw8ho5.default-release$ grep .css /tmp/t.out
newfstatat(AT_FDCWD, "/home/ishikawa/.config/gtk-3.0/gtk.css", 0x7ffc9a8f58f0, 0) = -1 ENOENT (No such file or directory)
access("/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userContent.css", F_OK) = 0
stat("/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userContent.css", {st_mode=S_IFREG|0644, st_size=869, ...}) = 0
openat(AT_FDCWD, "/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userContent.css", O_RDONLY) = 42
access("/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userChrome.css", F_OK) = 0
stat("/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userChrome.css", {st_mode=S_IFREG|0644, st_size=1165, ...}) = 0
openat(AT_FDCWD, "/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userChrome.css", O_RDONLY) = 42
ishikawa@ip030:~/.mozilla/firefox/uwbw8ho5.default-release$ cd /home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome
ishikawa@ip030:~/.mozilla/firefox/uwbw8ho5.default-release/chrome$ ls -l *.css
-rw-r--r-- 1 ishikawa ishikawa 1165 10月  4 17:11 userChrome-example.css
-rw-r--r-- 1 ishikawa ishikawa 1165 10月  4 17:55 userChrome.css
-rw-r--r-- 1 ishikawa ishikawa  869 10月  4 17:11 userContent-example.css
-rw-r--r-- 1 ishikawa ishikawa  869 10月  4 17:11 userContent.css
ishikawa@ip030:~/.mozilla/firefox/uwbw8ho5.default-release/chrome$ 

THEN I changed userContent.css as a symlink to another real file.
So I started firefox. At least, it did not get hung.

strace -o /tmp/t.out firefox 
[GFX1-]: glxtest: VA-API test failed: failed to initialise VAAPI connection.
ATTENTION: default value of option mesa_glthread overridden by environment.
[2022-10-04T09:20:22Z ERROR glean_core::metrics::ping] Invalid reason code startup for ping background-update
[2022-10-04T09:20:31Z ERROR mp4parse] Found 2 nul bytes in "\0\0"
[2022-10-04T09:20:31Z ERROR mp4parse] Found 2 nul bytes in "\0\0"
[2022-10-04T09:20:31Z ERROR mp4parse] Found 2 nul bytes in "\0\0"
[2022-10-04T09:20:31Z ERROR mp4parse] Found 2 nul bytes in "\0\0"
ishikawa@ip030:~/.mozilla/firefox/uwbw8ho5.default-release/chrome$ 
ishikawa@ip030:~/.mozilla/firefox/uwbw8ho5.default-release/chrome$ grep userContent.css /tmp/t.out
access("/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userContent.css", F_OK) = 0
stat("/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userContent.css", {st_mode=S_IFREG|0644, st_size=869, ...}) = 0
ishikawa@ip030:~/.mozilla/firefox/uwbw8ho5.default-release/chrome$ ls -l ./*.css
-rw-r--r-- 1 ishikawa ishikawa 1165 10月  4 17:11 ./userChrome-example.css
-rw-r--r-- 1 ishikawa ishikawa 1165 10月  4 17:55 ./userChrome.css
-rw-r--r-- 1 ishikawa ishikawa  869 10月  4 17:11 ./userContent-example.css
lrwxrwxrwx 1 ishikawa ishikawa   20 10月  4 18:19 ./userContent.css -> /tmp/userContent.css
ishikawa@ip030:~/.mozilla/firefox/uwbw8ho5.default-release/chrome$ 

But, I am not sure if it read the content of userContent.css at all. There is no |openat()| call anymore.

When I make userChrome a symlink additionally, the following is what happens.
firefox starts and exit as I instructed it.
From the strace output:

grep '.css' /tmp/t.out
newfstatat(AT_FDCWD, "/home/ishikawa/.config/gtk-3.0/gtk.css", 0x7ffe688e0460, 0) = -1 ENOENT (No such file or directory)
access("/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userContent.css", F_OK) = 0
stat("/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userContent.css", {st_mode=S_IFREG|0644, st_size=869, ...}) = 0
access("/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userChrome.css", F_OK) = 0
stat("/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userChrome.css", {st_mode=S_IFREG|0644, st_size=1165, ...}) = 0
openat(AT_FDCWD, "/home/ishikawa/.mozilla/firefox/uwbw8ho5.default-release/chrome/userChrome.css", O_RDONLY) = 42
ishikawa@ip030:~/.mozilla/firefox/uwbw8ho5.default-release/chrome$ 

So it seems that userChrome.css is read (see |openat| system call above. I don't see anything similar for userContent.css above.
BTW, I have simply copied the content of user{Content,Chrome}-example.css to corresponding files.

ishikawa@ip030:~/.mozilla/firefox/uwbw8ho5.default-release/chrome$ ls -l /tmp/*.css
-rw-r--r-- 1 ishikawa ishikawa 1165 10月  4 18:25 /tmp/userChrome.css
-rw-r--r-- 1 ishikawa ishikawa  869 10月  4 18:18 /tmp/userContent.css
ishikawa@ip030:~/.mozilla/firefox/uwbw8ho5.default-release/chrome$ 

This is with 105.0.1 (64-bit) under Debian GNU/Linux.

I reverted the change to |toolkit.legacyUserProfileCustomizations.stylesheets| (setting to false) and FF no longer accesses the .css files.
OK.

I will post what I find for Windows build.

Comment 19

[Daniel Holbert [:dholbert]]

This seems to be WORKSFORME.

I followed the STR from comment 0, in Windows 11, to create a folder chrome and then a symlink inside of it userContent.css, inside of my Firefox profile folder (found via about:support "open folder"), in an administrator-run cmd.exe shell. After that, Firefox (v113.0.1) still starts up just fine.

I then tried setting toolkit.legacyUserProfileCustomizations.stylesheets to true and quit & reopened Firefox. It still started just fine.

I then created userContent.css in my home directory (where the symlink is pointing) and gave it just one line, * { border: 1px solid red }, and then I started Firefox. Again it started just fine, and I saw red borders around lots of UI components, indicating that the userContent.css symbolic link is being successfully opened and followed.

So: this seems to work fine these days.