Closed Bug 682706 Opened 13 years ago Closed 2 years ago

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

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Version:
6 Branch
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: sh, Unassigned)

References

Details

(Keywords: hang, regression)

Attachments

(1 file)

WinDbg log
(deleted), application/x-zip
Details
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.
Summary: When userChrome.css is a symbolic link on Windows Vista or 7, firefox does not start up, seems to fall into a busy loop. → When userContent.css is a symbolic link on Windows Vista or 7, firefox does not start up, seems to fall into a busy loop.
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
Blocks: 541496
Status: UNCONFIRMED → NEW
Component: General → Style System (CSS)
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: general → style-system
Hardware: x86_64 → x86
Attached file WinDbg log (deleted) —
Keywords: hang
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/Ms2ger@gmail.com-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.)
(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/Ms2ger@gmail.com- > 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.
Ms2ger, see comment 4
(In reply to Ms2ger from comment #6) > Thanks Boris. > > Reporter, Alice, please see > <https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/Ms2ger@gmail.com- > 3763efcc1bcd/try-win32/> Nothing improved. the result is same as comment#0
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?
(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?
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.
(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...
Ms2ger, do you have a Windows build env? Or should I try to dust mine off?
As a workaround you can symlink the chrome folder instead. cd Profiles/xxx.default mklink chrome C:\Users\username\chrome
Edit mklink /d chrome C:\Users\username\chrome
Severity: normal → critical
I'll add that Firefox 51.0.1 (64 bits) on OSX will not load userContent.css if it is a symlink.

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.

Severity: critical → --

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.

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.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: