1239886 - [e10s] tabs with invalid about: url show infinite spinner

Status: RESOLVED INACTIVE

(Firefox :: Tabbed Browser, defect, P2)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20160112030227
STR:
1. Open new tab
2. Type/paste "about:permissions" in urlbar, press Enter 
3. Wait until error page is displayed
4. Open new tab
5. Switch to the tab from Step 2
6. Click "Stop loading this page" button in urlbar

Result:       
 After Step 3 Reload button is displayed in urlbar; the tab still shows blue "loading" spinner
 After Step 5 "Stop loading this page" button is displayed in the end urlbar
 After Step 6 nothing happens

Expectations: 
 After Step 3 the tab shouldn't show any icon
 After Step 5 Reload button should be displayed in the end urlbar

I think this happens in more cases, e.g. when a page couldn't be loaded because of connection error

Comment 1

[Tracy Walker [:tracy]]

I can reproduce this as reported.   Can also reproduce if just pasting garbage in a newtab location bar in step 2 above.  I am unable to reproduce with real pages.

Comment 2

[Tracy Walker [:tracy]]

The tab should just stop trying to load at some point which should solve both expectations; no spinner in the tab and no stop icon in the awesomebar.

Comment 3

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to [:tracy] Tracy Walker from comment #2)
> The tab should just stop trying to load at some point which should solve
> both expectations; no spinner in the tab and no stop icon in the awesomebar.

Sounds good to me. Are you asking if this should block m9?

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #3)
> (In reply to [:tracy] Tracy Walker from comment #2)
> > The tab should just stop trying to load at some point which should solve
> > both expectations; no spinner in the tab and no stop icon in the awesomebar.
> 
> Sounds good to me. Are you asking if this should block m9?

Asking your opinion in general. m8, m9, +?

Comment 5

[Jeff Griffiths (:canuckistani) (:⚡︎)]

m9 is my gut - I don't think we should block m8 for this.

Comment 6

[arni2033]

I just reproduced this with url   "data:image/jpeg;base64,A......."   (without outer quotes)

That url shows infinite spinner, but it's _gray_ spinner, not _blue_ spinner described in comment 0
Still I think this is the same issue.
Please tell if it requires another report (e.g. if they should be threated with different priority)

Comment 7

[Jim Mathies [:jimm]]

Interesting bug, here's what I'm seeing. Jeff, are we happy with the +/P1 designation?

non-e10s window
---------------

from www.google.com to data:image/jpeg;base64,A

The url bar changes back to www.google.com, no other visual indicators display.

from about:newtab to data:image/jpeg;base64,A

The url bar clears

^^ this is good behavior

e10s window
-----------

from www.google.com to data:image/jpeg;base64,A

The url bar maintains 'data:image/jpeg;base64,A' and content remains on google.com

^ bug!

from about:newtab to data:image/jpeg;base64,A

Infinite tab navigation throbber

^ bug!

Comment 8

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Jim Mathies [:jimm] from comment #7)
> Interesting bug, here's what I'm seeing. Jeff, are we happy with the +/P1
> designation?

Thanks for the nudge. I agree that this bug, if you encounter it, is bad. We should fix it, and soon.

My opinion is that it shouldn't block, primarily because I think it would be pretty unusual for a typical user to encounter this bug in the wild - the user is required to use specifically crafted and I think rare urls.

If you have reason to believe users will commonly, in the wild, encounter these urls, we should set this to block. My gut instinct is no and I am not aware of any measurements that would help us.

Comment 9

[arni2033]

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #8)
> reason to believe users will commonly, in the wild, encounter these urls
I actually detected this bug after these steps (it's not common, but at least realistic example):

1. Open some big "data:" image in a new tab in GoogleChrome.
  (I actually opened image from GoogleChrome's home page in a new tab - it was in "data:" format)
2. Copy url of that image in clipboard
3. Open new tab in Firefox, paste string copied in step 2 into urlbar, press Enter.

AR:  After Step 2 - string is too long, so it becomes clipped by "...". After Step 3 - this bug.
ER:  No bug in Firefox  (I guess nothing can be done about how other browsers handle long strings)

Comment 10

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to arni2033 from comment #9)
> (In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #8)
> > reason to believe users will commonly, in the wild, encounter these urls
> I actually detected this bug after these steps (it's not common, but at
> least realistic example):
> 
> 1. Open some big "data:" image in a new tab in GoogleChrome.
>   (I actually opened image from GoogleChrome's home page in a new tab - it
> was in "data:" format)

Given this STR which is something few end-users would ever do, I have to say I'm still comfortable with +/P1 prioritization.

Comment 12

[Jim Mathies [:jimm]]

added str:

1. open nightly
2. in the URL bar, type "https://"
3. hit enter

Comment 13

[Jim Mathies [:jimm]]

Jeff, based on new str, are you still ok with the current priority?

Comment 14

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Jim Mathies [:jimm] from comment #12)
> added str:
> 
> 1. open nightly
> 2. in the URL bar, type "https://"
> 3. hit enter

I can't reproduce, I get "The address isn't valid". Is this platform-specific?

Comment 15

[:Gijs (he/him)]

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #14)
> (In reply to Jim Mathies [:jimm] from comment #12)
> > added str:
> > 
> > 1. open nightly
> > 2. in the URL bar, type "https://"
> > 3. hit enter
> 
> I can't reproduce, I get "The address isn't valid". Is this
> platform-specific?

No; it's correct that you see the error page, but the connecting/loading spinner **on the tab** keeps going indefinitely after the error page appears.

Comment 16

[Jim Mathies [:jimm]]

we have a bunch of these currently open, trying to get them all hooked up to 'e10s-spinner'. See comment 15.

Comment 17

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to :Gijs Kruitbosch from comment #15)
> (In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #14)
> > (In reply to Jim Mathies [:jimm] from comment #12)
> > > added str:
> > > 
> > > 1. open nightly
> > > 2. in the URL bar, type "https://"
> > > 3. hit enter
> > 
> > I can't reproduce, I get "The address isn't valid". Is this
> > platform-specific?
> 
> No; it's correct that you see the error page, but the connecting/loading
> spinner **on the tab** keeps going indefinitely after the error page appears.

I don't see the spinner, OS X 10.10, latest nightly. Doesn't really matter, I believe you and I think priority is still fine.

Comment 19

[:Gijs (he/him)]

From the dupe:

But the infinite spinner on the tab (bug 1239886) still happens for invalid URIs as well. In the testcase for the broken URL ("foo bar" without keyword.enabled ie search from the address bar) case I added in bug 1267289, if you were to add assertions for ok(!tab.hasAttribute("busy"), "Tab stops spinning"); next to the existing ones about the URL bar, those assertions will fail. In fact, I looked into fixing that for a bit and then I gave it up as too much of a (mostly unrelated) rats nest next to the URL bar case. :-\

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

Moving to p2 because no activity for at least 24 weeks.
See How Do You Triage for more information

Comment 21

[Sylvestre Ledru [:Sylvestre]]

I don't think we have that anymore and we didn't have much activity on this bug for a while, closing.