Panorama video (Aza version) mysteriously plays when browser is launched

VERIFIED FIXED

Status

defect
P2
normal
VERIFIED FIXED
9 years ago
3 years ago

People

(Reporter: marcia, Assigned: mitcho)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [hardblocker])

This bug comes to us courtesy of John O'Duinn, who showed it to Juan and I moments ago.

Specifics:

*John is using a 3.6 profile and is now running FF 4 Beta 8
*He noticed the issue the other day when his audio was on 
*He checked all his tabs and that video is **not** loaded in any of them
*If you go into Panorama on his machine, the new video is there and it plays.

https://bugzilla.mozilla.org/show_bug.cgi?id=596201 has had some work on it recently. 

Is this possibly some sort of caching issue?
So after rechecking Beta 9, I see that the Aza version is still the default video. I had erroneously thought that the video had been changed.

But the issue still remains of why the video plays on John's machine without him even being in Panorama (he mentioned that he did not think he had ever even launched Panorama in that profile). It does not look like to me that video autoplays, but I may be wrong.
Summary: Old Panorama video (Aza version) mysteriously plays when browser is launched → Panorama video (Aza version) mysteriously plays when browser is launched
Component: General → TabCandy
QA Contact: general → tabcandy
1) This only happens when I start Firefox. Given how rarely I start it *and* have audio unmuted, I have no idea when first this started happening. I first noticed earlier this week when I left the laptop unmuted by accident and restarted Firefox. As demonstrated in QA lab yesterday, I can start/stop Firefox multiple times in a row and demonstrate this happening every time I start Firefox.

2) I confirmed by looking at every single window and tab, that I do *not* have a Panorama (or a whats new) page loaded anywhere.

3) I've just upgraded from beta8->beta9 and on restart of Firefox I get the same autoplay of the audio of the Panorama video. Grrr....
created new profile and still have the exact same behavior.

Start Firefox, do nothing
Wait for pages to load
Be surprised by autorun of audio of Panorama video
Confirm that no panorama windows are open
Exit Firefox
Repeat.


cc-ing Tomcat, Legneato because this also reproduces with a clean new profile.
I can't imagine that this only happens on Mac... is that true?
Priority: -- → P2
Whiteboard: [creepy ghost of aza]

Comment 5

9 years ago
The default panorama set has an intro video...seems strange that it is initializing without going into panorama previously (as comment 3 says)
(In reply to comment #5)
> The default panorama set has an intro video...seems strange that it is
> initializing without going into panorama previously (as comment 3 says)

Indeed. At least according to our code, the intro video tab is only opened when someone initializes Panorama. Note, however, that Panorama can be "initialized" if you hover over the "move tab to" menu item. Is it possible that this happened, John?

Moreover, the intro video will only load if browser.panorama.experienced_firstrun is set to false (the default profile setting). This should get set to true during that initialization of the video... John, could you manually check this pref setting value before and after the creepy voice begins? If this value is sticking, this behavior should only happen at most once.

Finally, it's worth noting that this only happens now because http://www.mozilla.com/firefox/panorama/ redirects to a url with just the video (a temporary measure, as the real page has not been finalized yet (bug 596201)) which starts autoplaying on load. I will make a note on the webpage bug (bug 596201) to please not autoplay the video on the page there. That way, in the future, even if Panorama is somehow initialized accidentally, it may open up that welcome page tab in the background but will not start playing the video.
Depends on: 596201
This is happening to me on Vista. Also from a profile that's come through other versions, using nightlies. I also have *no tab* that has anything like this open anywhere. I even tried opening the panorama view to see if there was a tab there, nothing.
OS: Mac OS X → All
Hardware: x86 → All
ARGGH!! Sorry, it's a bit frustrating as the video is the last thing to load, so for about 20 seconds I think maybe it's better, but no, there it is.

My browser.panorama.experienced_firstrun is set to true.  Will try setting it to false and see what happens.
Set it to false, audio started. Hit ctrl+e to trigger panorama, it started *another* audio, I didn't actually see the tab in that case either, but there was a second tab area in the panorama view, when I killed it it terminated the second audio, first one kept playing.
bah, so knowing where the video is supposed to live I typed "webm" into the awesome bar and it did find a tab with the video in my regular tab set. I did check all my tabs several times, so I can't tell you how I missed it, but it was there!
(In reply to comment #9)
> Set it to false, audio started. Hit ctrl+e to trigger panorama, it started
> *another* audio, I didn't actually see the tab in that case either, but there
> was a second tab area in the panorama view, when I killed it it terminated the
> second audio, first one kept playing.

Huh, so maybe it is indeed another copy.

(In reply to comment #10)
> bah, so knowing where the video is supposed to live I typed "webm" into the
> awesome bar and it did find a tab with the video in my regular tab set. I did
> check all my tabs several times, so I can't tell you how I missed it, but it
> was there!

Hmm, fascinating. So, after you typed webm and switch to that video's tab, what other tabs were in the tab bar, i.e. what group is it in? And then when you zoom back out into Panorama, does that webm video tab *now* show up in Panorama? Or is it still not showing up?

Majken, now that you have verified that browser.panorama.experienced_firstrun is set to true, can you keep it set to true and restart your browser and see if it happens again? I ask because it's possible that this only happens when experienced_firstrun is false, but the playing of the video made it true. I'd like to know if it happens if you start with true.
Sorry if it wasn't clear, but in my case it doesn't seem to be such a big mystery. I had a tab open that I hadn't found before.  I don't use panorama, all my tabs are in one stack. It was in the middle.  Closing the tab worked as expected, problem solved!

My guess would be something changed so that the video auto plays. I *think* I may have been given that link and had left the page open intentionally meaning to watch it sometime and it got lost in my other tabs. The tab doesn't say anything about panorama or tab candy so that explains how I would have missed it (though I remember going through all tabs checking for video, I can only assume I wasn't as thorough as I thought I'd been).

Hopefully the same is true for John's case, that it's an open tab and that he didn't actually start with a clean profile, otherwise this will be fun to track down!

Comment 13

9 years ago
This should be a hard blocker, since it happens to people who launch the browser after opening Panorama for the first time.
blocking2.0: --- → ?
I actually think we should just remove the firstrun video altogether; I think I commented to that effect in another bug.
blocking2.0: ? → final+
Whiteboard: [creepy ghost of aza] → [hardblocker]
(In reply to comment #14)
> I actually think we should just remove the firstrun video altogether; I think I
> commented to that effect in another bug.

Mike, I assume you mean replacing it with the welcome page (bug 596201)? Or are you referring to an idea (which would be new to me) to completely remove this firstrun behavior?
Mozilla/5.0 (Windows NT 6.0; rv:2.0b10pre) Gecko/20110118 Firefox/4.0b10pre

This is easily reproducible for anyone. Make sure the first run pref is unset and relaunch the browser. Open panorama and you can see the tab opened for the first run video, but it's opened in another group so invisible to the user.

Now, if you have Firefox set to remember tabs from last launch (and not present the save state dialog) it will keep coming back forever...
Somehow reset is creating a new background group and placing the first run video into it.
Adding the background tab is expected behavior on panorama startup when experienced_firstrun=false. It's loading a tab which goes to http://www.mozilla.com/firefox/panorama/, which will host our Panorama welcome page (bug 596201). At some point the mozilla.com folks started getting that URL to redirect directly to the video which autoplays instead of 404ing, as it was for a while.

Will this issue not simply be resolved when that URL actually points to a webpage without an autorun video (bug 596201)?
(In reply to comment #18)
> Adding the background tab is expected behavior on panorama startup when
> experienced_firstrun=false.

How can that possibly make sense? Now every a user with the aforementioned settings opens the browser it will open the background tab forever? Opening background tabs is not a good design choice IMO, even if the forever issue is resolved. If the tab is opened _when_ and only when panorama is opened, that would probably be fine...
(In reply to comment #19)
> If the tab is opened _when_ and only when panorama is opened, that
> would probably be fine...

That is the design.
(In reply to comment #20)
> That is the design.

With the exception that hovering the context menu item triggers it as well. That is probably what the meat of this bug is. I'm still not sure why it has to be a new "background" tab...
(In reply to comment #21)
> (In reply to comment #20)
> > That is the design.
> 
> With the exception that hovering the context menu item triggers it as well.
> That is probably what the meat of this bug is. I'm still not sure why it has to
> be a new "background" tab...

We're trying to avoid that situation as well: i.e., not have Panorama get loaded in the background by hovering over the context menu item, unless the user has already used Panorama before and has been shown the welcome tab when Panorama is visible. Bug 626525.
Depends on: 626525
(In reply to comment #15)
> Mike, I assume you mean replacing it with the welcome page (bug 596201)? Or are
> you referring to an idea (which would be new to me) to completely remove this
> firstrun behavior?

I mean getting rid of the video entirely, and if it vastly simplifies things, the firstrun experience. It was a nice to have, but I don't think I'd block the release on it. We can still do all the bookkeeping about whether or not a user has run Panorama before or not, just not open the tab until we have the appropriate content there.

I guess that would be a new bug, yes?
(In reply to comment #23)
> (In reply to comment #15)
> > Mike, I assume you mean replacing it with the welcome page (bug 596201)? Or are
> > you referring to an idea (which would be new to me) to completely remove this
> > firstrun behavior?
> 
> I mean getting rid of the video entirely, and if it vastly simplifies things,
> the firstrun experience. It was a nice to have, but I don't think I'd block the
> release on it. We can still do all the bookkeeping about whether or not a user
> has run Panorama before or not, just not open the tab until we have the
> appropriate content there.
> 
> I guess that would be a new bug, yes?

Well, would my request to undo the redirect of the Panorama welcome url to the video in bug 596201 not solve this for the near term?
Yes, it would solve it for the near term, but it wouldn't solve the issue around:

 - localizing the video
 - updating the video content
 - updating the web page content

I think the better thing to do would be to not open the tab (filed bug 626754 for that) until those tasks are done. Then we can re-enable that bit of code.
FYI, we disabled the redirection to the video so http://www.mozilla.com/firefox/panorama/ is now a 404 again.
Bug 626754 is the only thing that blocks this now, as that's the direction we decided to take.
Assignee: nobody → mitcho
No longer depends on: 596201, 626525
(In reply to comment #10)
> bah, so knowing where the video is supposed to live I typed "webm" into the
> awesome bar and it did find a tab with the video in my regular tab set. I did
> check all my tabs several times, so I can't tell you how I missed it, but it
> was there!

Interesting. I note that I carefully looked through all my tabs+windows for any open parorama tab before *and* after restarting Firefox with new clean profile, and it did not have a 

However, when I typed in "webm" as Lucy outlined above, awesome bar let me "switch to tab" to webm video playing panorama. And it switched to a tab that I know was not visible when I checked just before.

Maybe the panorama video tab is somehow being treated differently to other "normal" tabs, and this is a hide/display bug for this tab?
(In reply to comment #26)
> FYI, we disabled the redirection to the video so
> http://www.mozilla.com/firefox/panorama/ is now a 404 again.

This explains why the Panorama clip is no longer playing for me on start of Firefox. I've restarted Firefox twice this evening, both times no Panorama webm clip.

Earlier this morning I restarted Firefox, and yet again heard-but-could-not-see, the Panorama webm clip. Not sure exact time, but think it was before comment#26. Looks like disabling the redirect to the webm clip nailed it...or to be precise, nailed the symptom. 

What will be the final shipping configuration for Panorama clip ? I'm concerned if we re-add a webm clip closer to FF4.0 release date, this bug will re-occur.
(In reply to comment #29)
> What will be the final shipping configuration for Panorama clip ? I'm concerned
> if we re-add a webm clip closer to FF4.0 release date, this bug will re-occur.

We're definitely going to once remove the firstrun "create a welcome tab" experience (bug 626754) and, if we get a Panorama welcome page in time and we resolve some of these other edge cases for Panorama getting activated inadvertently, it's possible we will reinstate the welcome tab (bug 626926). But more and more (see what happened to bug 596201) it's looking like we may not reinstate it, at least for fx4.

That's the latest, John. :)
This is resolved now that bug 626754 has landed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
This is verified on 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10) Gecko/20100101 Firefox/4.0b10
Status: RESOLVED → VERIFIED
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.