96118 - location.replace(location.href+'#'+stuff) problem

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[av (gone)]

Not sure about Component. This bug could be related to bug 92651. Screen shots 
to follow.

Comment 1

[av (gone)]

Attachment: Mozilla screen shot

Comment 2

[av (gone)]

Attachment: IE screen shot

Comment 3

[sairuh (rarely reading bugmail)]

not sure if this should go to layout or i18n, but i don't believe it belongs in
xp apps. punt as needed.

Comment 4

[Mats Palmgren (inactive)]

This is not a Layout bug. It is related to the change of location.href that goes
on in the frame that does not work (http://gazeta.ru/lenta_body.shtml). It does
work when you go directly to it, but not when the parent URL has a # in it.
Here's the relevant script code:

<script language="javascript"><!--
function transform_url() {
h=parent.window.location.href;
i=h.indexOf('#');
if( i==-1 ) i=h.indexOf('?');
if(i!=-1){
    j=h.substr(i+1,666);
    location.replace(location.href+'#'+j);
} 
} 
//--></script>
<script language="javascript"><!--
transform_url();
//--></script>

Comment 5

[Mats Palmgren (inactive)]

*** Bug 100026 has been marked as a duplicate of this bug. ***

Comment 6

[Asa Dotzler [:asa]]

->DOM

Comment 7

[Fabian Guisset]

I'm unable to debug this because I can't seem to access
http://gazeta.ru/lenta_body.shtml
I don't see a problem with the function pasted earlier in this bug.

Comment 8

[av (gone)]

Maybe it was down, it is accessible now. Articles at the original link are
different now but it still exhibits exactly the same problem.

Comment 9

[Mats Palmgren (inactive)]

*** Bug 133030 has been marked as a duplicate of this bug. ***

Comment 10

[Mats Palmgren (inactive)]

*** Bug 133244 has been marked as a duplicate of this bug. ***

Comment 11

[John Keiser (jkeiser)]

Offhand I'd suggest looking at the line: j=h.substr(i+1,666);

Comment 12

[Mats Palmgren (inactive)]

The site has been changed so it avoids the problem with an early return.
We still need to find out whether this is bug in Mozilla or not.

<script language="javascript"><!--
function transform_url() {
if(navigator.appName.indexOf=='etscape') return;      // HERE
if(location.href.indexOf('#')!=-1) return;
h=parent.window.location.href;
i=h.indexOf('#');
if( i==-1 ) i=h.indexOf('?');
if(i!=-1){
    j=h.substr(i+1,666);
    location.replace(location.href+'#'+j);
} 
} 
//--></script>

Comment 13

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 14

[Mats Palmgren (inactive)]

AFAICT we are calculating the new URL the same way IE does it for exmaple.
(Which is "http://gazeta.ru/lenta.shtml#100035#100035")

But why was it only a problem in Mozilla?
Is it 'location.replace()' that rejects the URL in other browsers?
Or do they just chop off the last "#100035"?

Comment 15

[av (gone)]

The site works fine now. I don't know if something got fixed along the way or
the site itself has changed, but feel free to mark it WFM.

Comment 16

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 17

[Jason K Carter]

I also experience this bug.  I have set up an example page on
http://maizecoop.cropsci.uiuc.edu/bugzilla1/

It seems as if the calling object of location.replace() happens to be a frame
other than the frame from which location.replace() is called, this error is
produced.

Comment 18

[Jason K Carter]

I don't seem to be experiencing this bug anymore using Mozilla 1.5 or 1.6.  Can
anyone else confirm that this has been fixed?

Comment 19

[Boris Zbarsky [:bzbarsky]]

What we're doing makes perfect sense, and since the site is fixed....