Closed
Bug 57756
Opened 24 years ago
Closed 23 years ago
Clicking on a URL in the address card pane loads the web page in the address book window
Categories
(SeaMonkey :: MailNews: Address Book & Contacts, defect, P3)
SeaMonkey
MailNews: Address Book & Contacts
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: sfraser_bugs, Assigned: jblanco)
References
Details
Attachments
(1 file, 5 obsolete files)
7.71 KB,
patch
|
Details | Diff | Splinter Review |
Make a new address book card, enter the person's details, and enter a URL. Commit the changes. Now click on that new card so that it loads in the address window. Click on the URL. Note that the URL loads in the address book window, replacing all the chrome in that window. The menus (on Mac) also become totally messed up. The only way out is to close the address book window.
Comment 2•24 years ago
|
||
We don't get the menus problem on Windows. Instead, all of the chrome for the AB disappears. I agree that this is lame, but I don't think this feature is high enough priority to warrant fixing for rtm. marking [rtm-]
OS: Mac System 8.5 → All
Whiteboard: [rtm-]
Comment 3•24 years ago
|
||
Couldn't you just add a target="_blank" attribute to both the cvHomeWebPage and cvWorkWebPage elements ?? That will launch a new browser window.
Linux (2001-03-13-08 mtrunk) Win32 (2001-03-13-10 mtrunk) Mac (2001-03-12-11 mtrunk) Re-test this bug and find no problem in these builds. Mark it worksforme
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Comment 8•23 years ago
|
||
Unsure why this bug was marked as verified since this problem still exists in the Mozilla 0.9.3 baseline. Clicking on the web page link replaces the address book window with the website with NO controls. This problem can be fixed by adding a target="_blank" attribute to both the cvHomeWebPage and cvWorkWebPage. Please reopen this bug.
Reporter | ||
Comment 9•23 years ago
|
||
This is still happening.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 10•23 years ago
|
||
To default owner.
Status: REOPENED → NEW
QA Contact: fenella → nbaca
Comment 13•23 years ago
|
||
*** Bug 72212 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
*** Bug 97296 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 15•23 years ago
|
||
Assignee | ||
Comment 16•23 years ago
|
||
With above changes, when user clicks on a url in the Address Book Card Viewer window, a new browser window will open with that url.
Reporter | ||
Comment 17•23 years ago
|
||
Do we always want a new window, or should it use the frontmost existing browser window if one exists?
Comment 18•23 years ago
|
||
Jessica, thanks for tackling this one also. cc'ing sspitzer. I think it should use the frontmost browser window like we do for clicking on a link in a mail window. Jennifer, any opinion?
Comment 19•23 years ago
|
||
The behavior should be the same as when clicking on a link in the mail window.
Assignee | ||
Comment 20•23 years ago
|
||
Assignee | ||
Comment 21•23 years ago
|
||
Above patch includes fixes for bugs 92168 and 72213. User can now view email addresses and urls as links, click on an email address and a compose message window will come up, and click on a url and the page will come up in top browser window or open new browser window if one is not already open.
Comment 22•23 years ago
|
||
r=bhuvan.
Updated•23 years ago
|
Updated•23 years ago
|
Attachment #54233 -
Flags: review+
Comment 23•23 years ago
|
||
Comment 24•23 years ago
|
||
Comment 25•23 years ago
|
||
here's an updated patch, based on jessica's original patch. one problem with the original patch was that when mousing over the web page links, the mouse would not change (indicating it was a link). so, I copied her trick putting a box around the <a> node. but if you use href, we open in the ab window. if we do target="new", we'll always open in a new window, not the top most. I use onclick="return openLink()" and always return false from openLink() so that we don't do the href.
Comment 27•23 years ago
|
||
other difference between the last patch and the original patch is that if the html links are not visible, I don't do the , if the html links are not visible, I don't do the setAttribute().
Comment 28•23 years ago
|
||
Comment 29•23 years ago
|
||
Updated•23 years ago
|
Attachment #53624 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #55422 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #54233 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #55426 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #55424 -
Attachment is obsolete: true
Comment 30•23 years ago
|
||
fixed. thanks for the patch, jessica.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 31•23 years ago
|
||
Trunk build 2001-11-13-03: WinMe Trunk build 2001-11-09: Linux RH 7.1, Mac 9.1 Verified Fixed, it now opens a browser window displaying the page.
Status: RESOLVED → VERIFIED
Comment 32•23 years ago
|
||
whoops, the home page link is not blue, like the other links. I've logged another bug for that, fix in hand.
Comment 33•23 years ago
|
||
see http://bugzilla.mozilla.org/show_bug.cgi?id=112786
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•