Bug 8552 - (int-154607) URLs in emails from Exchange are parsed incorrectly
(int-154607)
: URLs in emails from Exchange are parsed incorrectly
Status: RESOLVED FIXED
Product: Synchronization
Mail for Exchange
: 5.0/(3.2010.02-8)
: N900 Maemo
: Unspecified normal with 2 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: unassigned
: activesync-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2010-01-26 18:40 UTC by Jason Harper
Modified: 2010-03-15 20:56 UTC (History)
2 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Jason Harper (reporter) 2010-01-26 18:40:42 UTC
SOFTWARE VERSION:
(Settings > General > About product)
2.2009.51-1.002

EXACT STEPS LEADING TO PROBLEM: 
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
1. Configure a MfE acct against Exchange 2003 (other Exchange servers untested)
2. Receive an email containing a URL containing one or more ampersand (&)
chars. Email can be either plain text or html.  Example URLs:
"http://www.somehost.com/somepath?p1=one&p2=two" and
"http://talk.maemo.org/showthread.php?t=35136&goto=newpost"
3. Observe the underlined portion of the URL
4. Click on the URL to visit the link in the browser

EXPECTED OUTCOME:
The entire URL is underlined and passed to the browser (especially for html
emails where the sender specified the entire URL in the href attribute)

ACTUAL OUTCOME:
The URL is considered to end at the first & character, truncating the URL (so,
for the examples above, the url is considered to be
"http://www.somehost.com/somepath?p1=one" and
"http://talk.maemo.org/showthread.php?t=35136").  This makes it very difficult
to visit links in many emails.

REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
Always

EXTRA SOFTWARE INSTALLED:
numerous

OTHER COMMENTS:
This problem doesn't appear to exist with other email account types (I tried
Gmail/IMAP).  Note that this occurs even when the email is in html format and
the link is properly composed in the email.   I've also checked the emails both
via Outlook Web Access and Outlook 2007 and the links appear correct on the
Exchange server both for plaintext emails and html emails.

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)
AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.38 Safari/532.0
Comment 1 Andre Klapper maemo.org 2010-01-27 15:40:04 UTC
Thanks for reporting this.
Comment 2 pepitoe 2010-02-03 16:26:03 UTC
Can confirm, here are the results of my tests using this link...

http://www.phpbb.com/community/viewtopic.php?f=64&t=1958635&start=45

I noticed that Outlook 2007 didn't seem to be putting links inside <a> tags in
html mails, but even a mail with correct html tags sent from Gmail to my
Exchange accont had the same issue.

Gmail
Plain Text - ok
Correct HTML - ok
HTML but link not tagged - not detected as link

Exchange
Plain Text - linked only up to first &
Correct HTML - linked only up to first &
HTML but link not tagged - linked only up to first &
(see bug 8222, html messages may be displayed as plain text currently)
Comment 3 Andre Klapper maemo.org 2010-02-15 11:47:09 UTC
Jason, is this bug reproducable only with MfE account or with IMAP accounts as
well? E.g., if you receive the very same message via IMAP account, will it work
properly?
Comment 4 Jason Harper (reporter) 2010-02-18 00:14:28 UTC
(In reply to comment #3)
> Jason, is this bug reproducable only with MfE account or with IMAP accounts as
> well? E.g., if you receive the very same message via IMAP account, will it work
> properly?

I only tried Gmail/IMAP, but the problem did not appear to exist with IMAP.
Comment 5 Andre Klapper maemo.org 2010-03-01 18:23:32 UTC
This has been fixed in package
as-daemon 0.0.3-31+0m5
which is part of the internal build version
10.2010.08-12
(Note: 2009/2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 6 Andre Klapper maemo.org 2010-03-15 20:56:11 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).