Note: There are a few cases of duplicates in user autocompletion which are being worked on.

chrome directory missing in fresh profiles

RESOLVED FIXED in seamonkey2.10

Status

SeaMonkey
Startup & Profiles
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Ant, Assigned: InvisibleSmiley)

Tracking

({regression})

Trunk
seamonkey2.10
regression

SeaMonkey Tracking Flags

(seamonkey2.7 wontfix, seamonkey2.8 wontfix, seamonkey2.9 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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/.

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 1

6 years ago
Confirmed with trunk, Linux and Windows.
Keywords: regression
OS: Windows XP → All
Hardware: x86 → All
Version: SeaMonkey 2.5 Branch → Trunk
(Assignee)

Updated

6 years ago
Summary: Linux's SeaMonkey v2.5(?)+ does not provide a chrome directory in profile accounts. → chrome directory missing in fresh profiles

Updated

6 years ago
Keywords: regression
Summary: chrome directory missing in fresh profiles → SeaMonkey v2.5(?)+ does not create and populate a chrome directory in new profiles.
Version: Trunk → SeaMonkey 2.5 Branch

Updated

6 years ago
Keywords: regression
(Assignee)

Updated

6 years ago
Summary: SeaMonkey v2.5(?)+ does not create and populate a chrome directory in new profiles. → chrome directory missing in fresh profiles
Version: SeaMonkey 2.5 Branch → Trunk
(Assignee)

Comment 2

5 years ago
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
Assignee: nobody → jh
Status: NEW → ASSIGNED
Attachment #604622 - Flags: review?(bugspam.Callek)
Attachment #604622 - Flags: approval-comm-aurora?
(Assignee)

Comment 3

5 years ago
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.
status-seamonkey2.10: --- → affected
status-seamonkey2.7: --- → wontfix
status-seamonkey2.8: --- → wontfix
status-seamonkey2.9: --- → affected
tracking-seamonkey2.10: --- → ?
tracking-seamonkey2.9: --- → ?

Comment 4

5 years ago
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?
(Assignee)

Comment 5

5 years ago
(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 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.
Attachment #604622 - Flags: review?(bugspam.Callek)
Attachment #604622 - Flags: review+
Attachment #604622 - Flags: approval-comm-aurora?
Attachment #604622 - Flags: approval-comm-aurora+
(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.
(Assignee)

Comment 8

5 years ago
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
Attachment #604622 - Attachment description: patch → patch [Checkin: Comment 8]
(Assignee)

Updated

5 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
status-seamonkey2.10: affected → ---
status-seamonkey2.9: affected → fixed
tracking-seamonkey2.10: ? → ---
tracking-seamonkey2.9: ? → ---
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.10

Comment 9

5 years ago
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

5 years ago
> Regression: 
Please file a new bug.

Comment 11

5 years ago
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.
(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

5 years ago
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.
(Assignee)

Updated

5 years ago
Blocks: 817295
You need to log in before you can comment on or make changes to this bug.