window.home() incorrectly handles multiple home pages specified with |

ASSIGNED
Assigned to

Status

()

Core
DOM
ASSIGNED
11 years ago
3 years ago

People

(Reporter: Michael Ventnor, Assigned: jst)

Tracking

(4 keywords)

Trunk
fixed1.8.0.12, fixed1.8.1.4, helpwanted, privacy
Points:
---
Bug Flags:
blocking1.8.1.4 +
blocking1.8.0.12 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060526 BonEcho/2.0a3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060526 BonEcho/2.0a3

Whenever the window.home() function is called and the user has multiple home pages specified, Firefox will attempt to load it as one gigantic URL instead of handling it properly.

Reproducible: Always

Steps to Reproduce:
1. Specify home page URL's separated by |. I used "http://en-US.start.mozilla.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official|http://video.google.com/"
2. Clicking the home button handles this correctly.
3. Now type in "javascript:window.home()" in the address bar. Firefox will attempt to load it all as one page.

Actual Results:  
Firefox tries to load the specified URL's as one long URL.

Expected Results:  
Firefox should either a) Open the first URL in the current tab and all other URL's in new tabs as is the default behaviour, or b) Offer different behaviour for window.home() and open just the first URL in the current tab, since many sites would assume you only have one home page.

Safe Browsing's "Get me out of here!" is also showing this behaviour, my guess is that Safe Browsing calls window.home()?
(Reporter)

Comment 1

11 years ago
Actually scratch (b) from my suggestions, I reckon everyone using this feature would expect (a) to happen.

Comment 2

11 years ago
See also bug 221445.  This might get fixed there.

Comment 3

11 years ago
I'd rather see behavior (b) in this case since it might not be obvious to the user that his/her homepage(s) were loaded which can be confusing if a web page suddenly spawns several tabs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → general
Severity: major → normal
Component: General → DOM
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → ian
Hardware: PC → All
Version: unspecified → Trunk

Updated

11 years ago
Depends on: 221445
(Reporter)

Comment 4

11 years ago
(In reply to comment #3)
> I'd rather see behavior (b) in this case since it might not be obvious to the
> user that his/her homepage(s) were loaded which can be confusing if a web page
> suddenly spawns several tabs.
> 

In that case, would strtok solve this issue? I don't have a compiler so I can't make or test a patch myself...

Comment 5

11 years ago
As long bug 221445 doesn't change the separator from the pipe to some character which isn't valid in URLs (e.g. a space), splitting up the homepage is no option. The apparently mis-behaving code is also used by other applications (e.g. SeaMonkey) which allow pipes as regular characters. Breaking these just because some Firefox devs once made an unlucky decision isn't likely to be happening.

Comment 6

11 years ago
After firefox just updated itself, it showed the "Firefox has been Updated" page:

http://www.mozilla.com/firefox/updated

with a link (bottom left) "Go to my home page" of:

javascript:window.home();

I have three homepages setup (stored with the | character) and clicking this link tried to load the combined URL in the current tab.  I agree with the additional poster that the expected result should be (a) Open the first URL in the current tab and all other URL's in new tabs.

Comment 7

11 years ago
I'm going to guess that the reason this hasn't been fixed yet is because there hasn't been any agreement on what to make the home method do.

I myself would like it to only open the first homepage in the tab, but if there could also be a preference to the behavior of the method, along with the home button. Only problem is that might confuse some people by making them think that if they set it to only open the first homepage, the browser will only open one page at start-up.
*** Bug 349414 has been marked as a duplicate of this bug. ***

Comment 9

11 years ago
*** Bug 347945 has been marked as a duplicate of this bug. ***

Comment 10

11 years ago
*** Bug 354678 has been marked as a duplicate of this bug. ***

Comment 11

11 years ago
At least you could try to avoid using javascript:window.home(); But after updating to v2.0, you'll see http://de.www.mozilla.com/de/firefox/2.0/whatsnew/ with a button linked to the javascript function again. I guess I'm not the only one who stumbles over this bug just because of the whatsnew-page right after updating.

Comment 12

11 years ago
(In reply to comment #11)
> I guess I'm not the only
> one who stumbles over this bug just because of the whatsnew-page right after
> updating.

Yes, you are not. I just upgraded to Firefox 1.5.0.8 and found the bug.
window.home() is used here: http://www.mozilla.com/en-US/firefox/updated

This is a PRIVACY ISSUE as it reveals to the server of my first home page the URLs of my others pages.
(Reporter)

Updated

11 years ago
Flags: blocking1.9?
Keywords: relnote

Updated

11 years ago
Duplicate of this bug: 366422
Marking blocking due to privacy issue. At the very least we could simply grab the first url and use that when window.home() is called
Assignee: general → jst
Flags: blocking1.9? → blocking1.9+
(Reporter)

Comment 15

11 years ago
(In reply to comment #5)
> The apparently mis-behaving code is also used by other applications
> (e.g. SeaMonkey) which allow pipes as regular characters. Breaking these just
> because some Firefox devs once made an unlucky decision isn't likely to be
> happening.

#ifdef MOZ_PHOENIX should be a viable option then, at least for the time being. I may sound like someone who's capable of fixing this but I'm not. I'm a C++ newbie (I usually stay within the javascript parts of Mozilla) but I thought I could easily fix this bug. Boy was I wrong. I really need to learn C++ and the internals of Mozilla :)

(Reporter)

Updated

11 years ago
Keywords: helpwanted, privacy
(Assignee)

Comment 16

11 years ago
Created attachment 254589 [details] [diff] [review]
Fix the privacy issue.

This solves the privacy issue involved here, but doesn't actually fix the problem. I don't think we can, or even want to, fix the actual problem here before bug 221445 is fixed. This is based on Michael Ventnor's idea of using MOZ_PHOENIX to determine whether we need to do this or not.
Attachment #254589 - Flags: superreview?(dveditz)
Attachment #254589 - Flags: review?(jonas)
(Assignee)

Comment 17

11 years ago
Josh, is this something that we need to worry about for Camino as well?
Attachment #254589 - Flags: review?(jonas) → review+
(Reporter)

Comment 18

11 years ago
Thanks Johnny, I had no idea NSStrings had those functions which is probably why I had so much trouble fixing it myself. :/ This looks like a nice, trivial bandaid for the 1.8 branch. Is it a good idea to request approval1.8.1.3?
(Assignee)

Comment 19

11 years ago
Yes, given that this is a potential privacy problem, absolutely!
Status: NEW → ASSIGNED
Flags: blocking1.8.1.3?
Duplicate of this bug: 370563

Comment 21

11 years ago
smorgan - is this an issue for Camino?

Comment 22

11 years ago
(In reply to comment #21)
> smorgan - is this an issue for Camino?

It shouldn't be, since Camino doesn't currently support multiple home pages, and isn't going to use Firefox's display method when we do.

See also bug 189930 for how we're planning to do this.

Updated

11 years ago
Duplicate of this bug: 371766
Flags: blocking1.8.1.3?
Flags: blocking1.8.1.3+
Flags: blocking1.8.0.10+
Comment on attachment 254589 [details] [diff] [review]
Fix the privacy issue.

sr=dveditz
Attachment #254589 - Flags: superreview?(dveditz) → superreview+
(Assignee)

Updated

11 years ago
Attachment #254589 - Flags: approval1.8.1.3?
Attachment #254589 - Flags: approval1.8.0.11?
(Assignee)

Comment 25

11 years ago
Privacy issue fixed on the trunk, leaving bug open to track the remaining problem that won't be fixed until bug 221445 is fixed.
(Reporter)

Comment 26

11 years ago
Is there a reason why this is targetted for approval on 2.0.0.4 and not .0.3?
(In reply to comment #26)
> Is there a reason why this is targetted for approval on 2.0.0.4 and not .0.3?

The approval1.8.1.3 flag was renamed to approval1.8.1.4 in preparation for a quicker than usual 1.8.1.3 release for critical bug fixes only.
Flags: blocking1.8.0.10+ → blocking1.8.0.12+
Comment on attachment 254589 [details] [diff] [review]
Fix the privacy issue.

approved for 1.8.0.12 and 1.8.1.4, a=dveditz for drivers
Attachment #254589 - Flags: approval1.8.1.4?
Attachment #254589 - Flags: approval1.8.1.4+
Attachment #254589 - Flags: approval1.8.0.12?
Attachment #254589 - Flags: approval1.8.0.12+
(Assignee)

Updated

10 years ago
Keywords: fixed1.8.0.12, fixed1.8.1.4
(Assignee)

Comment 29

10 years ago
Unmarking the blocking1.9 flag here as the privacy issue here is now fixed. The reminder is not a blocker.
Flags: blocking1.9+
QA Contact: ian → general
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.