Last Comment Bug 728840 - chrome directory missing in fresh profiles
: chrome directory missing in fresh profiles
Status: RESOLVED FIXED
: regression
Product: SeaMonkey
Classification: Client Software
Component: Startup & Profiles (show other bugs)
: Trunk
: All All
: -- normal (vote)
: seamonkey2.10
Assigned To: Jens Hatlak (:InvisibleSmiley)
:
Mentors:
Depends on:
Blocks: 817295
  Show dependency treegraph
 
Reported: 2012-02-20 04:13 PST by Ant
Modified: 2012-12-01 07:34 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
wontfix
wontfix
fixed


Attachments
patch [Checkin: Comment 8] (1.02 KB, patch)
2012-03-10 03:19 PST, Jens Hatlak (:InvisibleSmiley)
bugspam.Callek: review+
bugspam.Callek: approval‑comm‑aurora+
Details | Diff | Review

Description Ant 2012-02-20 04:13:52 PST
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) 2012-02-20 08:29:06 PST
Confirmed with trunk, Linux and Windows.
Comment 2 Jens Hatlak (:InvisibleSmiley) 2012-03-10 03:19:41 PST
Created attachment 604622 [details] [diff] [review]
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) 2012-03-10 03:28:39 PST
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 2012-03-10 04:41:05 PST
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) 2012-03-10 04:48:45 PST
(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) 2012-03-10 14:45:32 PST
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) 2012-03-10 14:46:18 PST
(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 9 NoOp 2012-11-17 16:54:16 PST
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 2012-11-18 03:30:07 PST
> Regression: 
Please file a new bug.
Comment 11 NoOp 2012-11-18 18:36:20 PST
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) 2012-11-18 19:26:19 PST
(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 2012-11-18 19:58:08 PST
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.

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