Closed
Bug 104998
Opened 23 years ago
Closed 19 years ago
pasting in URL to document body should update URL bar
Categories
(SeaMonkey :: Location Bar, enhancement, P4)
Tracking
(Not tracked)
RESOLVED
FIXED
Future
People
(Reporter: jmd, Assigned: hewitt)
References
Details
(Keywords: helpwanted)
Attachments
(1 file)
734 bytes,
patch
|
Details | Diff | Splinter Review |
On UNIX you can middle click to paste a URL into the body, and have Mozilla go there. This should also update the URL bar, to show where it's going. The status bar is so horked so half the time that loses track of what's happening, and all you have is the wait cursor to let you know *something* is happening.
Comment 1•23 years ago
|
||
->url bar, or...?
Component: XP Apps: GUI Features → URL Bar
QA Contact: sairuh → claudius
Assignee | ||
Updated•23 years ago
|
Severity: normal → enhancement
Status: NEW → ASSIGNED
Keywords: helpwanted
Priority: -- → P4
Target Milestone: --- → Future
Comment 3•23 years ago
|
||
For the record, I don't think I've ever seen the url bar not change after loading one of these. But this might be related to something I see all the time: when I load something via -remote, nothing at all happens in the browser window for quite a long time -- there's no status bar or throbber change to show that anything happened until the page is nearly entirely loaded, when suddenly the window comes alive and shows the new page. I'm forever clicking on urls in IRC two or three times thinking that I didn't click in the right place.
Reporter | ||
Comment 4•23 years ago
|
||
Akkana: it changes after loading, but not before it's done. For sites with slow DNS, or slow to establish a connection to port 80, or slow to send data, it's as you said with IRC... you can't tell anything is happening. If the URL bar was updated immediatly, it'd be just as if you paste the URL in there or typed it in. Once we have error pages instead of these damned, dirty dialogs, we'll need to show the attempted address anyway.
![]() |
||
Comment 5•23 years ago
|
||
jmd, try this out and let me know what you think?
![]() |
||
Comment 6•23 years ago
|
||
ccing blake, since this touches contentAreaClick
Reporter | ||
Comment 7•23 years ago
|
||
Boris: applied your patch, doesn't seem to change anything. Pasted in the url: "foogle.com", it stalled at DNS lookup, location never changed, even when the dialog poped up saying no response from host.
![]() |
||
Comment 8•23 years ago
|
||
Very odd. You rebuilt xpfe/ or rejarred the chrome (depending on whether you use a tree or patchmaker) afterward?
Reporter | ||
Comment 9•23 years ago
|
||
I did "pm help" to unpack, then "vi content/communicator/contentAreaClick.js" an manully made the changes, then restarted. I asked in #mozilla if any more had to be done and hwaara said no.
Comment 10•19 years ago
|
||
bz's patch made it in as part of bug 175092 and this works now
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•