193416 - mailnews start page gets cleared when I open the pref window

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[(not reading, please use [e-mail] instead)]

mailnews start page gets erased

when I open the pref window, my mailnews start page gets cleared out.

is anyone else seeing this?

note, the way browser does the start page pref (in pref-navigator.js and
pref-navigator.xul) is different that how we're doing it.

Comment 1

[(not reading, please use [e-mail] instead)]

here's the xul:

<textbox id="mailnewsStartPageUrl" flex="1" preftype="localizedstring"
  type="autocomplete" prefstring="mailnews.start_page.url"
  searchSessions="history" timeout="50" maxrows="6" class="uri-element"/>

if I remove all the autocomplete related attributes, it works:

type="autocomplete" searchSessions="history" timeout="50" maxrows="6"
class="uri-element"

I'm not sure when this broke.  I'd much rather figure out why this stopped
working, and see if there is a good fix, rather than making pref-mailnews.js and
pref-mailnews.xul to be more like pref-navigator, which appears to handle this
pref by hand, instead of using the attributes that nsPrefWindow.js is supposed
to support.

before I dig into this, is anyone else seeing it?

Comment 2

[(not reading, please use [e-mail] instead)]

I queried, and didn't see other dups of this.

but I can't imagine I'm the only one.

Comment 3

[[e-mail]]

Doh, this is probably another regression of the URL bar hack :-/

Comment 4

[[e-mail]]

Attachment: Proposed patch

Comment 5

[(not reading, please use [e-mail] instead)]

Comment on attachment 114657 [details] [diff] [review]
Proposed patch

do we have a tracker bug for all the band-aid fixes for #90337?  (if so, we
should add this to it.)

Comment 6

[(not reading, please use [e-mail] instead)]

hoping for 1.3 final

Comment 7

[jag (Peter Annema)]

Comment on attachment 114657 [details] [diff] [review]
Proposed patch

I don't like this patch.

What do we need to do to really fix bug 90337 (and hopefully this bug)?

Comment 8

[[e-mail]]

In the long term, yes, but what's best for 1.3?

Comment 9

[Asa Dotzler [:asa]]

we'd consider taking a safe fix for this but we're not going to block on it. 

Comment 10

[[e-mail]]

Comment on attachment 114657 [details] [diff] [review]
Proposed patch

So jag, is this a safe fix for 1.3?

Comment 11

[jag (Peter Annema)]

Maybe we could take this on the 1.3 branch, but I'm afraid that if we stick this
on the trunk that it's gonna stay there, like so often happens with these hacks.

Comment 12

[(not reading, please use [e-mail] instead)]

upgrading severity.  

Comment 13

[matsuba]

User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3) Gecko/20030307

I use 1.3 Candidate for Linux version.

It seems that the start page of Mail & Newgroups will be initialized to the
following timing.

Reproducible: Always

Steps to Reproduce:
1. [Edit (E)] of browser -> mail & newsgroup In the state where it opened [OK]
It pushes.   
2. Exit Mozilla.
3. A setup in prefs.js becomes empty. 

The following case seems to be satisfactory.

a. Mail & Newsgropus is not opened. [OK] When it pushes.
b. In the state where Mail & Newsgroups was displayed [Cancel].

Please, hoping for 1.3 final !!

Comment 14

[Tobias]

confirming this bug also exists in the latest Mozilla 1.3 test release available
on MozillaZine, released today
(http://www.mozillazine.org/articles/article2963.html). I am also hoping for a
fix in 1.3 final!

Comment 15

[(not reading, please use [e-mail] instead)]

if bug #90337 isn't going anywhere fast, I'd rather see this dataloss fixed, and
then backed out (with the other band aid fixes).

varga / jan / neil, suggestions?

Comment 16

[(not reading, please use [e-mail] instead)]

we shouldn't ship 1.4 with this.  (if there is a 1.3.1, I'd want to take a fix
there, too.)

Comment 17

[[e-mail]]

Attachment: Different approach

This tweaks the band-aid not to cut in if it appears to be unnecessary.

Comment 18

[(not reading, please use [e-mail] instead)]

what aspect of monster bug #90337 was the original bandaid for?

Comment 19

[(not reading, please use [e-mail] instead)]

neil tells me it was for this
(http://bugzilla.mozilla.org/show_bug.cgi?id=90337#c120)

"Hide the Navigation toolbar with the menuitem.
Close the browser.
Reopen and Show the Navigation toolbar.
Nothing in the URL bar works anymore."

neil, does your new bandaid still fix that problem?

Comment 20

[(not reading, please use [e-mail] instead)]

I wrote to neil:

> if your new bandaid still fixes that issue, and the pref dataloss issue, and 
> doesn't regress any other autocomplete consumers (compose, mailing lists) I'll 
> gladly sr it.

neil wrote:

> Better than that, you could even back out your patch to bug 190153!

can you come up with that complete patch then?

Comment 21

[[e-mail]]

Attachment: Patch with backout to fix to bad band-aid

Comment 22

[Jan Varga [:janv]]

Comment on attachment 118037 [details] [diff] [review]
Patch with backout to fix to bad band-aid

r=varga
please test it well

Comment 23

[jag (Peter Annema)]

Comment on attachment 118037 [details] [diff] [review]
Patch with backout to fix to bad band-aid

sr=jag

Comment 24

[(not reading, please use [e-mail] instead)]

I'm going to triage to adt1 / nsbeta1+, since this is dataloss.

thanks for the fix, neil!

Comment 25

[(not reading, please use [e-mail] instead)]

fix tested and landed.

thanks again neil.

Comment 26

[(not reading, please use [e-mail] instead)]

landed, so not blocking 1.4 alpha.

Comment 27

[(not reading, please use [e-mail] instead)]

back ported to 1.3.1

Comment 28

[Ninoschka Baca]

Trunk build 2003-04-10: WinXP, Mac 10.1.5, Linux RH 8.0
Verified Fixed.

Comment 29

[matsuba]

Mozilla 1.3.1 Release Candidate Builds
http://ftp.mozilla.org/pub/mozilla/nightly/latest-1.3.1/

Linux RH 8.0:
Linux RH 7.2:

Verified Fixed.