728840 - chrome directory missing in fresh profiles

Status: RESOLVED FIXED

(SeaMonkey :: Startup & Profiles, defect)

Description

[Ant]

User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14
Build ID: 20110420224920

Steps to reproduce:

Downloaded .tar.bz2 file, extracted to my ~/bin/seamonkey2/, started SM2, and used it.


Actual results:

It did not make a /home/<username>/.mozilla/seamonkey/<profilename>/chrome directory with two user example files like Firefox/Iceweasel in my Debian stable machine.


Expected results:

/home/<username>/.mozilla/seamonkey/<profilename>/chrome directory with two user example files should be created after using SeaMonkey once.

Philip Chee, in my news.mozilla.org's mozilla.support.seamonkey's "Does Linux SeaMonkey v2.7.2 have a chrome directory?" newsgroup, said this should not pack everything into an omni.jar they got moved to omni.ja!/defaults/profile/chrome/.

Comment 1

[Jens Hatlak (:InvisibleSmiley)]

Confirmed with trunk, Linux and Windows.

Comment 2

[Jens Hatlak (:InvisibleSmiley)]

Attachment: patch [Checkin: Comment 8]

This is what the Makefile.in under browser/ has, and it fixes it for me.

[Approval Request Comment]
Regression caused by (bug #): Move to omni.ja[r] (probably)
User impact if declined: No example CSS files
Testing completed (on m-c, etc.): No (but confirmed locally)
Risk to taking this patch (and alternatives if risky): Depends on review (low?)
String changes made by this patch: None

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

Each and every version since/including 2.1 is affected (2.0 and before are not, obviously). Too late for 2.8, but we should try and fix it for 2.9.

Comment 4

[Philip Chee]

You seem to have missed this bit:
http://hg.mozilla.org/mozilla-central/rev/fff61d7cc077#l3.72

Should a bug be filed to port the rest of bug 525438 (l10n-merge doesn't merge all files, make targets work with PRETTY_NAMES, too. Adding a l10n-checks target for a dummy repack) assuming that there are other bits that haven't been ported?

Comment 5

[Jens Hatlak (:InvisibleSmiley)]

(In reply to Philip Chee from comment #4)
> You seem to have missed this bit:
> http://hg.mozilla.org/mozilla-central/rev/fff61d7cc077#l3.72

I'll (have to) leave that up to the reviewer. I don't know much about (pre-) Makefiles, just tracked the issue this bug is about down to that file and line. For the same reason I cannot answer your further questions either; hopefully someone else can.

Comment 6

[Justin Wood (:Callek)]

Comment on attachment 604622 [details] [diff] [review]
patch [Checkin: Comment 8]

r+ if you change http://hg.mozilla.org/mozilla-central/rev/fff61d7cc077#l3.72 like Ratty suggested as well.

Comment 7

[Justin Wood (:Callek)]

(In reply to Philip Chee from comment #4)
> Should a bug be filed to port the rest of bug 525438 (l10n-merge doesn't
> merge all files, make targets work with PRETTY_NAMES, too. Adding a
> l10n-checks target for a dummy repack) assuming that there are other bits
> that haven't been ported?

I do agree that more work is necessary here, Not sure the proper breakdown of bugs though.

Comment 8

[Jens Hatlak (:InvisibleSmiley)]

Comment on attachment 604622 [details] [diff] [review]
patch [Checkin: Comment 8]

http://hg.mozilla.org/comm-central/rev/dc8ad83b7b86
http://hg.mozilla.org/releases/comm-aurora/rev/bf89b7ad6f3c

Comment 9

[NoOp]

Regression: 
User agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121026 Firefox/16.0 SeaMonkey/2.13.2
    Build identifier: 20121026204658

$ ls -al ~/.mozilla/seamonkey/tdji2edc.test
total 12084
drwx------  7 gg gg     4096 Aug 10 15:42 .
drwx------  5 gg gg     4096 Aug 10 15:35 ..
-rw-r--r--  1 gg gg   425984 Aug 10 15:38 addons.sqlite
drwx------  2 gg gg     4096 Aug 10 15:36 bookmarkbackups
drwxrwxr-x 18 gg gg     4096 Aug 10 15:35 Cache
-rw-------  1 gg gg    65536 Aug 10 15:42 cert8.db
-rw-------  1 gg gg      193 Aug 10 15:38 compatibility.ini
-rw-r--r--  1 gg gg   229376 Aug 10 15:35 content-prefs.sqlite
-rw-r--r--  1 gg gg   524288 Aug 10 15:35 cookies.sqlite
drwxr-xr-x  2 gg gg     4096 Aug 10 15:38 extensions
-rw-r--r--  1 gg gg      434 Aug 10 15:38 extensions.ini
-rw-r--r--  1 gg gg   458752 Aug 10 15:38 extensions.sqlite
-rw-------  1 gg gg    16384 Aug 10 15:42 key3.db
-rw-r--r--  1 gg gg     5765 Aug 10 15:39 localstore.rdf
-rw-r--r--  1 gg gg      482 Aug 10 15:38 mailViews.dat
drwx------  2 gg gg     4096 Aug 10 15:35 minidumps
-rw-r--r--  1 gg gg     1758 Aug 10 15:38 panels.rdf
-rw-rw-r--  1 gg gg        0 Aug 10 15:38 .parentlock
-rw-r--r--  1 gg gg    65536 Aug 10 15:38 permissions.sqlite
-rw-r--r--  1 gg gg 10485760 Aug 10 15:38 places.sqlite
-rw-------  1 gg gg     3283 Aug 10 15:38 pluginreg.dat
-rw-------  1 gg gg     3865 Aug 10 15:42 prefs.js
-rw-r--r--  1 gg gg     6012 Aug 10 15:40 search.json
-rw-------  1 gg gg    16384 Aug 10 15:35 secmod.db
-rw-------  1 gg gg      774 Aug 10 15:38 sessionstore.bak
-rw-------  1 gg gg     1182 Aug 10 15:42 sessionstore.json
drwxrwxr-x  2 gg gg     4096 Aug 10 15:40 startupCache
-rw-rw-r--  1 gg gg       10 Aug 10 15:42 virtualFolders.dat

Same with SeaMonkey 2.16a1.

Comment 10

[Philip Chee]

> Regression: 
Please file a new bug.

Comment 11

[NoOp]

Why? Is this not a regression? Did old/original code get put back in? This bug contains the original symptoms/fix. Don't you think that my creating a new bug, that essentially refers back to *this* bug report, a waste of buzilla/dev resources?

At the very least you/others could have a look to see if the issue is old/original code before asking that I file "yet another mozilla bug" report. If you (or Jens) have, and it is created by completely different code/patch than this bug, then I'll be happy to do so. If not, then you are simply wasting everyone's time by having me file a new bug report rather then reopening this one.

Comment 12

[Justin Wood (:Callek)]

(In reply to NoOp from comment #11)
> Why? Is this not a regression? Did old/original code get put back in? This
> bug contains the original symptoms/fix. Don't you think that my creating a
> new bug, that essentially refers back to *this* bug report, a waste of
> buzilla/dev resources?

Because we have a history/practice here at Mozilla of "one bug per issue/fix" if your issue isn't fixed in its landing, or regresses a NEW bug is needed so we can properly track.

Without doing so we have a far far far harder time tracking and dealing with the issues, and far harder time identifying what went wrong.

Not only now, but a month from now, a year from now, 5 years from now. etc.

Comment 13

[NoOp]

Interesting:
<http://www.seamonkey-project.org/dev/>
>>  <https://developer.mozilla.org/en/docs/Bug_writing_guidelines>
<https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/>

I'll just forget about it. We've most likely wasted more time on these comments than it would have taken to check the code.