Closed Bug 530272 Opened 16 years ago Closed 15 years ago

Clicking on mail links in Horde Webmail frequently generates a page with an incorrect base link

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mozilla, Unassigned)

Details

(Whiteboard: [CLOSEME - 1/30])

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:1.9.0.15) Gecko/2009102617 Camino/2.0 (like Firefox/3.0.15) Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:1.9.0.15) Gecko/2009102617 Camino/2.0 (like Firefox/3.0.15) Starting with Camino 2.0, when using Horde/Imp Webmail, following links from a mailbox listing to individual messages causes a weird interstitial login page to be returned instead, or simply the mailbox listing again. You would think that this would be more likely to be a problem with Horde than with Camino, but I have been using Horde for years now without this happening, it never happened with Camino versions prior to 2.0, and I can not reproduce the problem in Safari 4.0.4 or Firefox 3.5.5. Here is a more specific description of the problem: When reading mail using Horde Webmail, I load my inbox page in the first tab, then command-click every new message to open it in a separate tab. Normally once each tab has loaded, each has a message rendered in it as you would expect (behaviour prior to Camino 2.0). The format of a message page link is as follows: https://webmail.example.com/horde/imp/message.php?index=5551212 Where the message number (in this example 5551212) is a monotonically increasing Horde message identifier. However around 50% of the time now in Camino 2.0 (based on my empirical testing) when I click on these mail links, the page that ends up opening will show an address in the address bar of either: https://webmail.example.com/horde/login.php?url=%2Fhorde%2Fimp%2Fmessage.php%3Findex%3D5551212 or: https://webmail.example.com/horde/imp/mailbox.php?mailbox=INBOX In both cases, the actual page displayed is not the desired message, but what you would expect Horde to display if you entered what is in the address bar or clicked on a link containing that address. I can't tell if it happens more frequently when you open a lot of messages in individual tabs in rapid succession, or if it's just random. Again, from the description you would think this is a Horde problem rather than a Camino problem, and perhaps it is doing something weird based on the new user-agent or something like that. All I know is that it never, ever happened with earlier versions of Camino and it still does not happen with current versions of Safari and Firefox. So something about the new 2.0 version of Camino must be making it happen. Reproducible: Sometimes Steps to Reproduce: 1. Log in to Horde Webmail 2. Command-click on some messages to open them in new tabs 3. If you click on about 10 messages, guaranteed 2-8 of them will have magically changed to the wrong link and open as login screens or mailbox listings instead of messages. Actual Results: Page loaded: https://webmail.example.com/horde/login.php?url=%2Fhorde%2Fimp%2Fmessage.php%3Findex%3D5551212 or https://webmail.example.com/horde/imp/mailbox.php?mailbox=INBOX Expected Results: Should have loaded page: https://webmail.example.com/horde/imp/message.php?index=5551212 Default theme, no special customizations, downloaded as normal 2.0 release binary (no special build). MacBook Pro, Tiger (OS X 10.4.11), Intel.
Do you get the same behaviour if you spoof your user-agent as (exactly) Firefox 3, using http://pimpmycamino.com/parts/user-agent ?
This sounds like a cookie problem to me. I've never seen it with my Horde webmail. If you launch Camino with a fresh profile (http://pimpmycamino.com/parts/troubleshoot-camino can automate this for you), do you still see the bad behavior?
(In reply to comment #1) > Do you get the same behaviour if you spoof your user-agent as (exactly) Firefox > 3, using > > http://pimpmycamino.com/parts/user-agent > > ? Yes; I tried the user-agent string of my Firefox 3.5.5 install [Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5] and got the same behaviour. I also tried setting it to Safari 4.0.4 [Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_4_11; en) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10] and also reproduced the behaviour. So I guess it's not a response to the user-agent string. I also noticed another related malfeasance - occasionally when logging in to Horde initially to display the inbox, it redirects straight back to the login screen (with no error indicating a failed login) even though login/password are correct. Again, never happened with earlier Caminos nor other browsers. May be relevant: when you click on links in Horde, sometimes it routes you through an interstitial page of the form: https://webmail.example.com/horde/imp/redirect.php Maybe something is interfering with this redirect?
(In reply to comment #2) > This sounds like a cookie problem to me. I've never seen it with my Horde > webmail. If you launch Camino with a fresh profile > (http://pimpmycamino.com/parts/troubleshoot-camino can automate this for you), > do you still see the bad behavior? Relaunching Camino via troubleshoot-camino, I was not able to reproduce the problem - so far so good. However returning to my original profile, I was not able to make the problem go away, either by clearing all the cookies, throwing away the browser history, or both. Clearing the cookies did seem to reduce the prevalence of the problem though - with cookies cleared it seems to require more tabs to be opened in quick succession to make the problem appear, but it's hard to tell. It's possible that clearing the profile via troubleshoot-camino just made it necessary to open more tabs in quick succession to see the problem than I was able to do manually.
Are you still seeing this in your normal profile after clearing all related cookies (try it again just for good measure if you haven't cleared them recently)? Have you ever been able to reproduce it in a fresh profile at all?
(In reply to comment #5) > Are you still seeing this in your normal profile after clearing all related > cookies (try it again just for good measure if you haven't cleared them > recently)? Yeah, I was unable to get rid of it even when clearing all cookies. It seems reasonable that it's a cookie problem, but maybe it's one that comes back when cookies are set again after they have been set a certain number of times. I'm thinking that it could be some kind of cookie race condition when the cookie is being set repeatedly (by opening tens or hundreds of Horde tabs simultaneously) so that maybe the cookie is being read while being written or something like that? The problem was driving me totally crazy though so I had to revert to Camino 1.6.10, so I haven't tried it with the latest 2.0.1 minor update. I was going to wait till the next rendering engine rev (the rendering of Horde mail also looks quite different in 2.0 as opposed to 1.x, now it looks like how Firefox renders it, the fonts are uglier somehow, so maybe the problem is related to some internal engine element?) unless you think it's worth giving it a shot with 2.0.1. Are there any profile elements outside of ~/Library/Application Support/Camino/ that I should preserve if I want to clear the profile completely and then selectively add parts back in (most importantly the WindowState plist, which stores my tab state for Horde)? > Have you ever been able to reproduce it in a fresh profile at all? I was never able to reproduce it in a completely fresh profile (using troubleshoot-camino), but I suspect that it's because I was never able to manually open enough tabs at once to get it to appear - my WindowState opens typically between 100 and 200 Horde tabs at Camino launch.
I just tried out Camino 2.0.2 to see if the bug still exists. It does, even with a fresh profile (besides the saved window state). I tested it this way: I erased the whole Camino profile, then started Camino as if for the first time (so it created a brand new profile). Then I quit Camino, and copied in the former Windowstate.plist file, so that the next time I started Camino, it would automatically open 120 or so Horde Webmail tabs. As before, many of the tabs redirected to the Horde login, a "message not found" page, or a Horde config page.
(In reply to comment #7) > I just tried out Camino 2.0.2 to see if the bug still exists. It does, even > with a fresh profile (besides the saved window state). > > I tested it this way: > > I erased the whole Camino profile, then started Camino as if for the first time > (so it created a brand new profile). Then I quit Camino, and copied in the > former Windowstate.plist file, so that the next time I started Camino, it would > automatically open 120 or so Horde Webmail tabs. > > As before, many of the tabs redirected to the Horde login, a "message not > found" page, or a Horde config page. And just to be clear, doing this exact same thing works perfectly well in Firefox or earlier versions of Camino?
Yep, it's been working great with all Caminos up to and including 1.6.10. 2.0 was the first one that exhibited the weirdness. I just tried it again on Firefox 3.5.8, with a saved set of 150 Horde tabs. Did a full load a couple of times and wasn't able to produce the problem at all. So yeah, seems to work perfectly well in Firefox too.
Are you still seeing this, with either 2.0.x or a 2.1 nightly build?
Can you please respond to comment 10?
Whiteboard: [CLOSEME - 1/30]
Sorry for the delayed response - had a mailserver problem in early Jan so never got the notification of comment 10. The problem still exists in 2.0.6. However, I did notice that if I insert a pause of about half a second in between opening mail tabs, the problem does not show up. This would be consistent with some kind of race condition involving the cookies and/or the history. I was not able to replicate the problem with today's 2.1 nightly build. So it might be fixed in 2.1 (Yay!). Maybe something to do with the new history format?
Let's close this WORKSFORME in 2.1, then.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.