I don't know if this will still be relevant once Bug 1105523 lands, but thought I would file it anyway. Feel free to mark as invalid if this is not going to impact anything. STR: 1.) set loop.gettingStartedUrl to a local web page 2.) have that web page show a uitour infoPanel on the hello target 'loop-newRoom' when the page loads. 3.) open the hello panel and click "get started" Expected results: The infoPanel should display on top of the hello panel Actual results: Because the hello panel was already open when the page loaded, the infoPanel gets displayed underneath and is hidden.

(In reply to Alex Gibson [:agibson] from comment #0) > 2.) have that web page show a uitour infoPanel on the hello target > 'loop-newRoom' when the page loads. To clarify, the page is doing showMenu("loop") first, right?

(In reply to Matthew N. [:MattN] from comment #1) > (In reply to Alex Gibson [:agibson] from comment #0) > > 2.) have that web page show a uitour infoPanel on the hello target > > 'loop-newRoom' when the page loads. > > To clarify, the page is doing showMenu("loop") first, right? Correct yeah. I'm actually having to use a 500ms setTimeout between showMenu and showInfo, like so: Mozilla.UITour.showMenu('loop'); setTimeout(function() { Mozilla.UITour.showInfo( 'loop-newRoom', 'Start your first conversation!', 'One click creates a new room that you’ll next invite a freidn to join' ); }, 500); This avoids the issue if loading the page directly, but not if opening via the "Get started" link.

(In reply to Alex Gibson [:agibson] from comment #2) > Mozilla.UITour.showMenu('loop'); > setTimeout(function() { > Mozilla.UITour.showInfo( You should be using the 2nd argument to showMenu which is a callback for when the menu is ready. You shouldn't need a setTimeout in that case. I'm guessing that won't fix this issue though. I think the simplest solution is to close the panel when the getting started button is clicked. That's how most menus work anyways.

(In reply to Matthew N. [:MattN] from comment #3) > You should be using the 2nd argument to showMenu which is a callback for > when the menu is ready. You shouldn't need a setTimeout in that case. I'm > guessing that won't fix this issue though. This works, although the positioning seems to jump around for a second? > I think the simplest solution is to close the panel when the getting started > button is clicked. That's how most menus work anyways. How can I do this via the web?

(In reply to Alex Gibson [:agibson] from comment #4) > > I think the simplest solution is to close the panel when the getting started > > button is clicked. That's how most menus work anyways. > > How can I do this via the web? Sorry, I meant that we should fix this in Loop/Hello.

(In reply to Matthew N. [:MattN] from comment #5) > Sorry, I meant that we should fix this in Loop/Hello. Ah, got it - thanks.

This bug is no longer a blocker for fx-UITour-Hello, but seems to still exist when targeting the signIn/signUp elements.

Moving open UITour bugs to Firefox::Tours. Filter on firefox-tours-20150121.

Support for Hello/Loop has been discontinued. https://support.mozilla.org/kb/hello-status Hence closing the old bugs. Thank you for your support.