857555 - Adobe site stuck on reload loop

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Zac C (:zac)]

Page seems to be infinitely loading/reloading. It appears to get to the page load event and then start again.

STR:
1. Load nightly
2. Go: http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html
3. Sit back and observe

Replicated on:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130402 Firefox/23.0 ID:20130402030843 CSet: aae004a3c5d9

(also some other colleagues replicated it on Mac/Nightly but I didn't grab their build IDs. Appears to be 23.0 only.)

Comment 1

[Boris Zbarsky [:bzbarsky]]

I see this on Aurora 22 as well, but not Beta.

Zac, are you willing to hunt down a regression range on nightlies?

Comment 2

[Zac C (:zac)]

Sorry Boris I don't have the time or infrastructure setup to narrow the range right now.

I can confirm it still replicating today:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130421 Firefox/23.0 ID:20130421031002 CSet: 0d50cb959c46

Comment 3

[Boris Zbarsky [:bzbarsky]]

You don't really need infrastructure.  The ftp server is just there....

Time I can understand.  ;)

Comment 4

[Alice0775 White]

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/6d587302645a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130316 Firefox/22.0 ID:20130316145831
Bad:
http://hg.mozilla.org/mozilla-central/rev/0b052daa913c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130316 Firefox/22.0 ID:20130316160554
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6d587302645a&tochange=0b052daa913c

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/22b3fa2e22c1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130314 Firefox/22.0 ID:20130314223435
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/cfa16b1c70a3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130314 Firefox/22.0 ID:20130314223935
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=22b3fa2e22c1&tochange=cfa16b1c70a3
Triggered by: Bug 850517

Comment 5

[Boris Zbarsky [:bzbarsky]]

Alice, thanks!

I guess now we need to figure out whether the problem is the dynamic updating or the not overriding things... :(

Comment 6

[Alice0775 White]

Attachment: semi-reduced zip (open help.html)

Comment 7

[Zac C (:zac)]

Thanks for helping out Alice :)

Comment 8

[Boris Zbarsky [:bzbarsky]]

I bet the issue is here:

			if( docLocLastNode != lastNodeOf(top.frames["content"].location) ) {	// ...but it is being loaded elsewhere

followed by some location.replace() calls.

The toplevel frameset has a <frame name="content">.

There is no "content" property on windows in the spec, but we have it on nsIDOMWindow... The getter basically returns the same thing as window.top for web pages, and the primary content shell when called from chrome.

I wonder whether we could move this member to nsIDOMChromeWindow.  Or on branches, to make things safer, hack up the "look up a named frame" getter to check for frames actually named "content" and if that fails to do the current behavior.  Bobby, what do you think?

Comment 9

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky (:bz) from comment #8)
> I wonder whether we could move this member to nsIDOMChromeWindow.  Or on
> branches, to make things safer, hack up the "look up a named frame" getter
> to check for frames actually named "content" and if that fails to do the
> current behavior.  Bobby, what do you think?

I think we should definitely hack something in first to fix the regression, and then move content to be chrome-only. Otherwise, we could find ourselves in a backout pickle on beta.

I'm a bit confused by your suggestion though. Do I understand correctly that the page wants the iframe but is getting |top|? If so, it seems like we should instead hack the |content| getter to check if there's a named frame of the same name, rather than having the named frame lookup see if the name is |content|. Or am I misunderstanding?

Comment 10

[Boris Zbarsky [:bzbarsky]]

> Do I understand correctly that the page wants the iframe but is getting |top|?

Yes.

> If so, it seems like we should instead hack the |content| getter to check if there's a
> named frame of the same name

Hmm...  Yeah, that would work too, for this use case, and somewhat more closely matches the behavior we used to have.  Let's do that.

Comment 11

[Bobby Holley (:bholley)]

I can probably get to this in the next week or two. Feel free to take it if you can get to it sooner.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: Make window.content return an existing named frame with that name if there is one.

Comment 13

[Bobby Holley (:bholley)]

Comment on attachment 742046 [details] [diff] [review]
Make window.content return an existing named frame with that name if there is one.

Review of attachment 742046 [details] [diff] [review]:
-----------------------------------------------------------------

r=bholley. Thanks for taking this.

Comment 15

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e2d475778a00

Comment 16

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 742046 [details] [diff] [review]
Make window.content return an existing named frame with that name if there is one.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 850517 
User impact if declined: Some sites are broken
Testing completed (on m-c, etc.): Passes tests, fixes the two sites that are
   broken so far.
Risk to taking this patch (and alternatives if risky): Low risk.  More or less
   restores the behavior we used to have for .content in Firefox 21 and earlier.
String or IDL/UUID changes made by this patch:  None.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e2d475778a00

Comment 18

[Mitza]

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:23.0) Gecko/20130428 Firefox/23.0

Verified as fixed on Firefox latest nightly (Build ID:20130428031010).

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/010637f8c507

Comment 20

[Mihai Morar, (:MihaiMorar)]

I confirm the fix is verified on FF 22.b1:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0(20130514181517)

Comment 21

[alex_mayorga]

Confirming http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html loads and stays loaded on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130603 Firefox/24.0 ID:20130603031140 CSet: 198e38876f7e

Marking VERIFIED based on this and comment 20.

Comment 22

[jeff.peelman]

Using Nightly 25.0a1 build, I did not observe the endless loading/reloading that was reported by Zac C on 03 April 13.  Page appears to load in the expected fashion.  I was able to page forward and back using the arrow icons on the screen.
Hope this information helps.  ~ Jeff