Closed Bug 315312 (sm1.1) Opened 19 years ago Closed 18 years ago

SeaMonkey 1.1 tracking bug - features wanted in release.

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Version:
1.8 Branch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: csthomas, Unassigned)

References

(Depends on 3 open bugs)

Details

(Keywords: meta) 

This is a tracking bug for SeaMonkey 1.1 features.  SeaMonkey 1.1 is expected to be a feature release based on Gecko 1.8

TO NOMINATE A BUG: Comment with a bug # and argument for why the feature is wanted.

*DO NOT* modify the "depends on" or "blocks" field of this bug.

This bug is intended for feature tracking.  Use bugzilla's "blocking-seamonkey1.x?" flags for actual bugs and regressions.
I would nominate bug 255834 as this would give us feature parity for RSS with Thunderbird.
Summary: SeaMonkey 1.1 tracking bug → SeaMonkey 1.1 tracking bug - features wanted in release.
Please add:

Bugzilla Bug 19437
Bugzilla Bug 56690
Bugzilla Bug 137014
Bugzilla Bug 152391
Bugzilla Bug 161466
Bugzilla Bug 164421
Bugzilla Bug 205883
Bugzilla Bug 311028
(In reply to comment #2)
> Bugzilla Bug 164421
Bug 164421 is a meta bug, which isn't very useful since it'll probably never be completely "fixed".

> Bugzilla Bug 311028
I think that is supposed to be fixed for beta or 1.0 final.
It would be best to only nominate bugs here that 1) are about feature work and 2) have working patches attached.
All regressions, or real "bugs" in a sense that we have software errors in our application should be just nominated for blocking-seamonkey1.1a once we have that flag. And any features are unlikely to go into a release before they have working patches :)
(In reply to comment #3)
> (In reply to comment #2)
> > Bugzilla Bug 164421
> Bug 164421 is a meta bug, which isn't very useful since it'll probably never be
> completely "fixed".

(In reply to comment #4)
> It would be best to only nominate bugs here that 1) are about feature work and
> 2) have working patches attached.
> All regressions, or real "bugs" in a sense that we have software errors in our
> application should be just nominated for blocking-seamonkey1.1a once we have
> that flag. And any features are unlikely to go into a release before they have
> working patches :)

Sorry. I thought this was a tracking bug for features wanted in a release version.

Bug 164421 may be a "meta" bug, but those are certainly important features to include in a release if you want to win over "converts". I see no reason why it would not be completely fixed. 

(In reply to Worcester12345's comment #5)
> Bug 164421 may be a "meta" bug, but those are certainly important features to
> include in a release if you want to win over "converts". I see no reason why it
> would not be completely fixed. 

you must have 20+ coders in your hip pocket plus a plan to fix 30+ bugs. (the oldest BTW being open for 6.5 years)

But the idea of marketability is a valid one, suggest you pick THE most aggregious one of the 30 and nominate it.  (but surely bugs like "3rd party download managers not supported" don't deserve priority)


(In reply to comment #2)
> Please add:
> Bugzilla Bug 19437
> ...

Chris will prob appreciate nominations that have "argument for why the feature is wanted.", which should be possible in one line.


Perhaps Chris will disagree or support ... as this will be the first feature release it may be important that new features have *wide* appeal - features that *substantially* enhance the product and will keep the *most* possible users should probably be the standard.
on that note, business users might appreciate...

Bug 55557 multiple (advanced) search messages window - a niche item perhaps but very nice for people with tons of mail and who "research" it (plus but david might be near working on it and TB might not be keen on having it soon)

Bug 161338 Add 'To, CC, From or Bcc' to Advanced Search to search all addresses - office users often Bcc interested parties (see bug for more rationale) - 


Other:

Bug 50504 Context menu (right-click) for bookmarks (in main menu and Personal Toolbar) - may help stem erosion to firefox, huge vote count (60) and cc list ... likewise bug 19437

Bug 303850 drag & drop within bookmarks toolbar [eg Firefox] - productivity for bookmark hounds

Bug 111891 Implement vertical splitter in a document-view, [for] two panes - obviously too cool 


does bug 3341 still have wide appeal?
composer:

Bug 13383 Support WebDAV protocol for publishing - quite a few votes, some checkin already and partial patches, current status unclear
What about bug 18574 (restoring MNG support) ?
(In reply to comment #9)
> What about bug 18574 (restoring MNG support) ?

I believe that requires core changes, which we don't have the power to make (at least, not on branches).
Speaking of wide appeal, I bet there are some, maybe a lot on Bugzilla Bug 163993 which was tracking "Mozilla Bugs with Large Community Interest". I don't think bugzilla is yet able to do what the original intent of that bug was. 

Outstanding ones would be:
Bugzilla Bug 201307
Bugzilla Bug 193638
Bugzilla Bug 122698
Bugzilla Bug 116692
Bugzilla Bug 108455
Bugzilla Bug 105843
Bugzilla Bug 71105
(In reply to comment #10)
> (In reply to comment #9)
> > What about bug 18574 (restoring MNG support) ?
> 
> I believe that requires core changes, which we don't have the power to make (at
> least, not on branches).

It does changes to core code (mainly libimg + libpr0n and packaging stuff) but AFAICS the MNG stuff is all #ifdef'ed and the default is still to build with MNG/JNG disabled, so the binaries would not be disturbed. But the MNG patch needs a proper review.
CTho suggested that bug 288764 would be a possible good feature for 1.1, it would simplify the preferences for the less adventurous user, but still let the most adventurous users have all the preferences easily accessible.
I'm not sure if it counts as a feature - but if it does, I would like to nominate bug 301105 for 1.1. Native-styled mac menupopups is something that has been missing for years now, so I think it would be a noticable and positive change for SeaMonkey mac users (the style of current menupopups are, erm, very Mac OS 9.x - ish). 
(In reply to comment #14)
> I'm not sure if it counts as a feature - but if it does, I would like to
> nominate bug 301105 for 1.1. Native-styled mac menupopups is something that has
> been missing for years now, so I think it would be a noticable and positive
> change for SeaMonkey mac users (the style of current menupopups are, erm, very
> Mac OS 9.x - ish). 
> 

http://hem.fyristorg.com/s_her/301105/native.html This looks like a significant polish improvement.
Depends on: 301105
Bug 122698 - better behavior when you run SM a second time on *nix?

I'll go through the nominations again soon.
Nominating bug 171756

Add a confirmation dialog for (or just remove) "Remove All Passwords".
I nominate bug 306026 for 1.1

The underlying feature was checked in to MOZILLA_1_8_BRANCH, but the pref to disable it, is still missing.
Nominating bug 312489 (URLs concatenated when opening a home page tab group from desktop icon).
Yes:
Bug 19437 - no patch, but worth tracking here in case someone is looking for bugs to work on
Bug 50504 - not explicitly marking since this should happen anyway in bug 19437
Bug 152391 - I beleive FF2 will have something like this.
Bug 288764 - a simpler pref dialog would be nice
Bug 122698 - the current *nix launcher script pretty much sucks
Bug 71105 - would be useful, though the suggestions in the bug don't seem very good

Not sure:
Bug 3341
Bug 171756 - if we move to satchel for 1.5 does this still apply?
Bug 205883 - is it really that bad?
Bug 108455 - no effect for people who use the whole suite or just the browser, but probably still nice to have
Bug 325554 - sounds interesting

No:
Bug 161338 - very minor
Bug 303850 - I think this already works.
Bug 111891 - very niche, not sure if it's feasible to do well
Bug 13383
Bug 105843 - core
Depends on: 19437, 71105, 122698, 152391, 288764
We should take this opportunity to clean up some years-old issues such as these:

bug 43278
bug 57342
bug 61078
bug 63918
bug 150274

Some more recent issues to consider getting somewhere with:

bug 158032
bug 207862
Some triaging on the proposed mailnews bugs:

- doable:

Bug 55557: Sounds interesting and useful and not too complicated, but will need thoroughly testing.

Bug 61078: good first bug. ;-)

Bug 325554: hope to review that one soon.

- nice-to-have:

Bug 43278: This is really nagging for a long time, but needs real dedication. Definitely no easy branch thing. But some patch bits are already there, so there may be a chance if someone steps up.

Bug 150274: This requires good knowledge of the Mozilla drag and drop handling in general and of the mailnews xul/js structure in particular. Should be doable if one shows dedication...

Bug 161338: Nice to have, but no priority.

Bug 306026: Patch is there, so just someone needs to rerequest branch approval.

- not realistic:

Bug 71105: This bug consists mainly of whining and no patch is in sight. In fact, a solution would mean to preload the whole mailnews backend even if it probably wouldn't be used - but if biff is requested, why not? Anyway, this would require some backend changes and is not feasible for branch.

Bug 158032: The needed backend changes don't seem "branchy".

Bug 205883: This dialog is very messy imo, too, but I don't think rearranging it will help. I'd rather see it killed entirely and integrate the junk mail controls into the normal filtering mechanism, but that's for sure nothing to be done on branch/for SM1.1.

Bug 207862: The side-by-side of mail views and View->Thread menu is admittedly no UI highlight, but we need to have a real plan for restructuring that. Just moving around menu items is no good.
(In reply to comment #22)
> Bug 158032: The needed backend changes don't seem "branchy".

What do you mean by this?

> Bug 207862: The side-by-side of mail views and View->Thread menu is admittedly
> no UI highlight, but we need to have a real plan for restructuring that. Just
> moving around menu items is no good.

The plan is basically to improve the mailviews system so that it can do everything that the View-Threads items do.  See the dependencies.  How much more do you think we need before the plan becomes real?  We can at least have a go at fixing one or two dependencies, e.g. bug 218208 is blocking quite a few of the mailviews issues and looks doable to me.
> > Bug 158032: The needed backend changes don't seem "branchy".
> 
> What do you mean by this?

Noone has even started working on it (despite the occasional JS addon), the backend changes will have to be watched closely as you can destroy a lot if it isn't well-made. So it's not likely to get on the stable branch soon, imo.

> The plan is basically to improve the mailviews system so that it can do
> everything that the View-Threads items do.  See the dependencies.  How much
> more do you think we need before the plan becomes real?

Heh. Programmers should be at hand also, I guess... ;-)

> We can at least have a go at fixing one or two dependencies, e.g.
> bug 218208 is blocking quite a few of the mailviews issues and looks
> doable to me.
 
Yes, so it seems (without me having looked at the actual source).

I nominate bugzilla bug 156082
= Don't hide the tab bar when clicking the close box (and only one tab remains open)
(This is a bug when the preferences/tabs is set to NOT hide the tab bar when only one tab remains open ... and the user accidently clicks the close tab button - or equivalent - one too many times.)

This seems to be close to resolution according to the comments in bugzilla.
(And very annoying when it happens.)
What about bug 286367: In mail, the clear button remains disabled after a quick search. It's a quite old bug.
I nominate bug 258371 - "Search Messages" should have a preview pane

This would greatly improve productivity of "search messages" - putting it on par with quick search in terms of being able to easily move (view) from message to message. (a fix would make it available in both SM and TB)
Depends on: 337155
Don't know if this qualifies as a feature, but I'll like bug 174699 to be in: it's a very long standing polish issue...
(In reply to comment #29)
> Don't know if this qualifies as a feature, but I'll like bug 174699 to be in:
> it's a very long standing polish issue...

Looks like that will make it anyway.

(In reply to comment #30)
> please fix the annoying bug https://bugzilla.mozilla.org/show_bug.cgi?id=307672

As far as I know, nobody knows how to fix that, so it's unlikely to get fixed any time soon.
# 17917 roaming user support

further to the existing (awesome) roaming user feature I am using right now, please add support for the transfer of message filters ( I use IMAP mail), also consider encrypting/compressing on the fly, perhaps using master password as key, so then password file and auto-form fill won't be such a security loophole, and syncing won't be so sloooowoww but we still won't need a working ssl server.
This bug says "wanted" in its title for a reason, and I think it should be closed with the arrival of 1.1 Beta, as that will be the feature freeze.
Actually, I think we should close for beta and do that feature freeze very soon now, probably within the next two weeks or so. This also means that any bugs onj the dependency list of this one need to be fixed until then or they will stay mere wishes but won't actually be fixed in SeaMonkey 1.1 - and I think that's probably true for most of those that are still open today (even if I'd really like to have some of them, I think we should get 1.1 out the door soon and then really focus on suiterunner).
Will ths Win32 installer for SM v1.1 use the NSIS installer (ala Firefox v2.0) or continue to use the XPTools installer?

This will be xpinstall-based installer. NSIS work is being done for suiterunner only, AFAIK.
As Composer is still one of our "features", I think it would be great if we could port inline spellchecking, but there's no actual bug filed for it yet...
Bug 357876 - Add to installer registering of seamonkey.exe in registry for Windows Media Player
Bug 115215 (which has an unreviewed patch) would be simple but nice addition
SeaMonkey 1.1 is effectively done feature-wise.  Resolving bug.  I will consider filing a similar tracking bug for 1.5.

(In reply to comment #38)
> Bug 115215 (which has an unreviewed patch) would be simple but nice addition
> 

That patch is probably no good.  First, it's probably rotted some time in the past 4 years.  Second, that feature probably belongs only in tabbrowser - I doubt most tabboxes really would benefit from it.  Third, tabbrowser provides its own tracking of the "last used" tab, which any patch should take advantage of.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
(removing 350416 so people don't look here and wonder why it's not in sm1.1)
No longer depends on: 350416
bug #264167
https://bugzilla.mozilla.org/show_bug.cgi?id=264167#c4

Bug #284381

because after years we still cannot open attachments in .eml files nor see attached images
a better test case can be this one:
https://bugzilla.mozilla.org/attachment.cgi?id=108377&action=view

Is there any "Seamonkey 1.5 tracking bug - features wantes in release"?

Thanks for information
No, there isn't. And it's probably good that way, as you see from this bug how well that "process" works.
We better go with what we really get than with a list of wishes we can't fulfill.
Status: RESOLVED → VERIFIED
The procedure for trunk is much simpler. If a feature is developed, tested, reviewed and approved (not necessarily in that order) then it lands.
(Features left over from Bug 315312 tracked 1.1 features)
Bug 15322 (Bug 394288, Bug 428216)
Bug 71105 (isn't this fixed?)
Bug 90315
Bug 255834
Bug 288764

Bug 449728 (Write front-end code to make use of the backend introduced in bug 113934) was split off from bug 113934 when the latter morphed into a backend bug and was resolved FIXed).

Since a new tracking bug for 2.0 wanted features is contraindicated I'm putting this comment here.
No longer depends on: 113934
You need to log in before you can comment on or make changes to this bug.