Closed Bug 295280 Opened 20 years ago Closed 18 years ago

URL in mails are highlighted but clicking is a no-op in some folders

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 288348

People

(Reporter: sargastic, Unassigned)

Details

(Keywords: regression) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050523
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050523

URLs in mails or news articles are properly highlighted. But, in "random" cases,
clicking in the URL does not do anything, except create a new error in the
Javascript console, such as :

Error: uncaught exception: Load of http://the_requested_url denied.

Here, random means it seems to depend on the message itself, rather than depend
on the links in the message. And a given message always keeps the same
"property" (either its links will be loadable, or none of them will be).

Reproducible: Always

Steps to Reproduce:
Do you also see this behavior with a 1.8 (trunk) build?
If you save one of the messages and load it in the browser, does it have similar
problems there?
Version: unspecified → 1.7 Branch
I'm dowloading the 1.8 beta 1 release  source code to check. I'll keep you informed.
And no, if I save the message into an .eml file and then load it in the browser,
the links are properly active.
Okay, I've done a little homework.
Same problem with 1.8b1. BUT it seems I have narrowed the problem :

1/ links are always OK (loadable) when the mail is in the INBOX
2/ links are never OK when the message is in any other folder
(btw, I'm using an SSL-IMAP server).

"Always" and "never" should be taken with caution, since I did not check all my
messages in all my folders :-) But from the sampling I did, it holds true.

Here is my mozconfig, in case it's useful :
mk_add_options MOZ_CO_PROJECT=suite
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/build-dir
ac_add_options --prefix=/home/tools/mozilla
ac_add_options --enable-crypto
ac_add_options --enable-strip
ac_add_options --enable-optimize
ac_add_options --disable-ldap
ac_add_options --disable-xprint
ac_add_options --disable-gnomevfs
ac_add_options --disable-oji
ac_add_options --enable-application=suite
ac_add_options --disable-gnomeui
ac_add_options --disable-tests
if you move a message from inbox (or to inbox) does that break (or fix) the message?
Version: 1.7 Branch → Trunk
Moving from inbox "creates" the problem. Moving to inbox fixes it. 
Same thing if copying messages, not moving them.

With 1.8b1, and debug messages, I get :

WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
mozilla/caps/src/nsScriptSecurityManager.cpp, line 1414
JavaScript error: , line 0: uncaught exception: Load of http://the_url denied.

Same error with 1.7.8, but on another line if I remember properly (it's
recompiling currently). Always in CheckLoadURIStr, so it does come from the same
function.
With 1.7.8, same error (NS_ENSURE_TRUE(NS_SUCCEEDED(rv)), same file, line 1387.
There is NO problem with 1.7.3 (the version I currently use), compiled with the
same .mozconfig file.
can you try a clean profile (a new profile and then set up the mail account)?  I
would guess that you have some preference set that's triggering the behavior.
Keywords: regression
And you guessed right.
With a new profile, the problem seems to diseappear (I've not used my regular
mail account with this new profile, hence the "seems").
Okay, where shall I look (and stop bothering you) ?
The most likely place to look is prefs.js.  I'd start with anything that starts
with "capability." or "dom.".  Migrate them from your default profile to your
clean one until the clean one is broken.  Be sure not to copy any pref that
references your old profile directory. 
Problem solved by editing prefs.js (and only this file).
But the edited lines have nothing to do with capability.* or dom.*. It's
something weird in one of my (mail.identity/mail.server) pairs that made
everything go down the drain.
Well, I learned a lot of things about prefs.js :-)
Thanks ! I think you may close this "bug report".
hmm.  Which pref was it?  Something that worked with 1.7.3 should really
continue to work with more recent builds -- certainly with later 1.7.x builds.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
(In reply to comment #10)
> Problem solved by editing prefs.js (and only this file).
> But the edited lines have nothing to do with capability.* or dom.*. It's
> something weird in one of my (mail.identity/mail.server) pairs that made
> everything go down the drain.
> Well, I learned a lot of things about prefs.js :-)

I have the same error message in windows, which goes away with a clean profile - but I do want to identify the cause. And I find it odd that it happens in some folders and not others. bug 305112 related or same.

I don't get the error for messages in Inbox, trash, Drafts. 
I do get it in all other folders, including Templates.
Error: uncaught exception: Load of http://blah denied.

my extensions are chatzilla, Roaming, reporter and copyallurls (which apparently didn't completely uninstall when I used Extension Uninstaller)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060521 SeaMonkey/1.5a

Violhaine, What prefs did you find were bad - your solution in comment 10?

> Problem solved by editing prefs.js (and only this file).
> But the edited lines have nothing to do with capability.* or dom.*. It's
> something weird in one of my (mail.identity/mail.server) pairs that made
> everything go down the drain.


reopening and changing > OS=ALL (see comment 14)
Severity: normal → major
Status: RESOLVED → UNCONFIRMED
OS: Linux → All
Hardware: PC → All
Resolution: EXPIRED → ---
Summary: Some URL in mails are properly highlighted but clicking is a no-op → URL in mails are highlighted but clicking is a no-op in some folders
Ahem. This was a loooong time ago, and I forgot to report the edited lines here. 

My troubles seemed to arise because of some old mail data in the prefs.js file, which were still in the prefs.js (I believe they should have been destroyed when the Thunderbird account was destroyed, but you are the experts about all that). Same thing with old mail servers which where still in the prefs.js file. 
Relevant variables were mail.server.serverX (where X in [2-5], no server1 definition) and mail.identity.idX (same X in [2-5], no id1). Some serverX refered to ex-mail servers, but destroyed long ago.
From the few notes I can dig up just now, I had this kind of setup :

user_pref("mail.account.account2.server", "server2");
user_pref("mail.account.account3.identities", "id2");
user_pref("mail.account.account3.server", "server3");
user_pref("mail.account.account4.identities", "id3");
user_pref("mail.account.account4.server", "server4");
user_pref("mail.account.account5.identities", "id4");
user_pref("mail.account.account5.server", "server5");
user_pref("mail.accountmanager.accounts", "account2,account3,account4,account5")

(note : no mail.account.account2.identities, and identities do not obviously match the server it is associated to; may be this is normal, I dunno).

I made a manual cleanup of all oldie identities stuff, straigthened the above definitions which looked just plain weird to me and everything went ok thereafter.

Beware, this is what I remember. Maybe my memory is wrong, you know, Alzheimer and low cost memory banks do play dirty tricks.
If you need more data, I may be able to dig up something from my papers and backups.
Violhaine
would you agree this is a dup of bug 288348?
(In reply to comment #17)
> Violhaine
> would you agree this is a dup of bug 288348?
> 

It really looks like so.
thanks for checking

*** This bug has been marked as a duplicate of 288348 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.