Closed Bug 405541 Opened 13 years ago Closed 10 years ago

Location Bar don't revert back to the correct url of the tab when you middle click go after entering text, to open in a new tab

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 4.0b8
Tracking Status
blocking2.0 --- -

People

(Reporter: thebudman420, Assigned: alice0775)

References

Details

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007112605 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007112605 Minefield/3.0b2pre

url does not switch back to the url of the web page your looking at when you type a new address in the Location Bar and middle click the go button to open the url in a new tab.

Normally when you middle click the go button it is supposed to switch the url back the url of the web page on that tab.

Instead it is keeping what you type in the Location Bar there in that tab.

However if you erase the url that you typed in and switch to another tab then back to that tab it switches it back to the correct url.

This used to work fine in previous builds, I think it may be because the new implementation of the go button, Can anyone confirm?

Reproducible: Always

Steps to Reproduce:
1. Go to any Web Page.
2. Click on the location bar and type some text or a url.
3. Middle click go to open in a new tab.
4. Switch back to the tab you typed the new url in.
Actual Results:  
The url did not switch back to web page on that tab.

Expected Results:  
What should of happened is. The url should of switched back to the correct url of the tab after you middle clicked the go button.

Fresh profile, no extensions installed. 
Workaround. 
1. After you have done the above steps to reproduce. 
2. Erase the text in the Location bar on that tab. 
3. Switch to a new tab.
4. Switch back to that tab
5. The url is now back to the correct url of that tab.
Summary: Url don't Revert back to the url of the web page your looking at when you middle click go to open in new tab → Url don't switch back to the url of the web page your looking at when you middle click go to open in new tab
I did farther testing and realized that this bug has always existed, at least it does in Firefox 2, TabMixPlus seems to fix this bug and normally i use that extension, so when i was using a new profile and found the bug in the Trunk builds, i realized the bug was there, It would still be nice for this bug to be fixed by default, That is how it should work but it doesn't.
Summary: Url don't switch back to the url of the web page your looking at when you middle click go to open in new tab → Location Bar don't revert back to the correct url of the tab when you middle click go after entering text, to open in a new tab
reproducible on
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090129 Shiretoko/3.1b3pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
Bug 227826 is about the same thing but with Alt+Enter instead of middle mouse click.
Duplicate of this bug: 547405
Attached patch patch (obsolete) — Splinter Review
if (aTriggeringEvent instanceof MouseEvent) {
             // We have a mouse event (from the go button), so use the standard
             // UI link behaviors
-            openUILink(url, aTriggeringEvent, false, false,
-                       true /* allow third party fixup */, postData);
+            var where = whereToOpenLink(aTriggeringEvent, false, false);
+            if (where != "current") {
+              this.handleRevert();
+              content.focus();
+            }
+            openUILinkIn(url, where, true, postData);
             return;
           }


Once, determine where to open url from aTriggeringEvent, and if it is not current tab, then revert url text in the location bar and re-focus content.
blocking2.0: --- → ?
Target Milestone: --- → Firefox 4.0
This isn't a regression, right?
(In reply to comment #6)
> This isn't a regression, right?
I think that this is the bug that introduced by landing of Bug 279687 and Bug 339710.
Blocks: 279687, 339710
Wouldn't hold the release for this - doesn't block.
blocking2.0: ? → -
This bug has gotta worse as there is no workaround to fix it anymore. It causes major usability problems, 

For example if you type in an address middle click go to open the address in a new tab and I'm on a page i can't reload for any number of reasons then i will not be able to see the address of the page I'm on anymore as the only way to see the address after middle clicking go is to click reload!, 

Further more if you use stylish and this style http://userstyles.org/styles/35242 for it combine stop reload and go buttons then it will not revert back to go because the text you typed in the address bar doesn't revert back to the correct address of the page you are on this could also have security implications if on a bank site for instance when you do this. This must be fixed! Like i mentioned before tab mix plus used to fix this bug but now there is no fix for it, 

It also becomes even more of a pain in the butt if you do this several times like i do because it is faster to type what i want in the address bar and middle click go to open in a new tab and then it creates a problem where i don't know what page is what anymore because it wont show me the address I'm on just what i typed before. This could be considered a security problem as someone might enter information on the wrong site because of this, also to know what page your on you would have to reload all the tabs so they go back to showing the correct address. If i knew how to code i would fix this myself so I'm hoping someone will post a fix for this bug because there is a lot of problems it can cause besides what i mentioned.
Attachment #465315 - Attachment is patch: true
Attachment #465315 - Attachment mime type: application/octet-stream → text/plain
Attachment #465315 - Flags: review?(dao)
Comment on attachment 465315 [details] [diff] [review]
patch

>           if (aTriggeringEvent instanceof MouseEvent) {
>             // We have a mouse event (from the go button), so use the standard
>             // UI link behaviors
>-            openUILink(url, aTriggeringEvent, false, false,
>-                       true /* allow third party fixup */, postData);
>+            var where = whereToOpenLink(aTriggeringEvent, false, false);

nit: use let instead of var

>+            if (where != "current") {
>+              this.handleRevert();
>+              content.focus();
>+            }
>+            openUILinkIn(url, where, true, postData);

Can you write that like this instead?

openUILinkIn(url, where,
             { allowThirdPartyFixup: true, postData: postData });
Attachment #465315 - Flags: review?(dao) → review+
Assignee: nobody → alice0775
OS: Windows XP → All
Hardware: x86 → All
Attached patch patch revised-1Splinter Review
Attachment #465315 - Attachment is obsolete: true
Attachment #476200 - Flags: review+
Attachment #476200 - Flags: approval2.0?
Whiteboard: [checkin-needed]
Keywords: checkin-needed
Whiteboard: [checkin-needed]
Attachment #476200 - Flags: approval2.0? → approval2.0+
http://hg.mozilla.org/mozilla-central/rev/ea5446f9b37e
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: Firefox 4.0 → Firefox 4.0b8
Flags: in-testsuite?
Attached patch test v1Splinter Review
Attachment #488639 - Attachment is patch: true
Attachment #488639 - Attachment mime type: application/octet-stream → text/plain
You need to log in before you can comment on or make changes to this bug.