<div dir="ltr"><div><div>Thanks, Gijs - I'd like to resolve this one way or another.  How do we get that data for: <br><br>- how frequently
      people actually hit this page *and* then crash again immediately
      (for some meaning of that word) after restoring tabs.  <br>- how often people actually interact with
      the treeview, and how many people just click 'restore all tabs' or
      'close'.<br><br></div>Thanks in advance,<br></div><div>Michelle<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 21, 2017 at 2:15 PM, Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div class="m_-2949270695428792543moz-cite-prefix">While we *might* be able to have a
      reasonable idea (and this really isn't trivial - see Bill's
      message, but also think of how we sometimes show the 'slow script'
      dialog and point to the wrong code as being slow), I think it's
      highly unlikely we'll ever be confident enough to inadvertently
      uncheck the suspected tab automatically, thus basically destroying
      user data (including the back/forward history of that tab, form
      data, cookies, scroll positions - everything) in case we're wrong.<br>
      <br>
      Even if we tell the user this, that treeview is a pain to use, and
      it's very likely that unchecked tabs will be scrolled out of view
      in some cases. We know that users don't read long descriptive
      text. So we effectively show a page with a big highlighted button
      to restore everything - and then we restore everything except some
      of them, with no way for users to get those items back. That
      sounds like a terrible experience to me.<br>
      <br>
      It'd be really interesting to have more data about how frequently
      people actually hit this page *and* then crash again immediately
      (for some meaning of that word) after restoring tabs. It'd also be
      helpful to have data about how often people actually interact with
      the treeview, and how many people just click 'restore all tabs' or
      'close'. My suspicion would be that that data either points to a
      larger problem which won't be fixed by just not restoring the
      data, or that pursuing this is going to take more time and code to
      get right enough to enable it than is justified by the benefit.<span class="HOEnZb"><font color="#888888"><br>
      <br>
      ~ Gijs</font></span><div><div class="h5"><br>
      <br>
      On 21/02/2017 01:47, Bram Pitoyo wrote:<br>
    </div></div></div>
    <blockquote type="cite"><div><div class="h5">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>Hi Firefox devs,<br>
                    <br>
                  </div>
                  Michelle and I have been doing some copy and design
                  review of our error pages, and one that we were
                  looking at was <a class="m_-2949270695428792543moz-txt-link-freetext">about:sessionrestore</a>.<br>
                  <br>
                  Our current copy is:<br>
                  “You can try: Removing one or more tabs that you think
                  may be causing the problem”<br>
                  <br>
                  And the instruction that Michelle proposed was:<br>
                  “Here are two things you can try: […] Remove the
                  checkmark in front of the last tab or two you opened
                  and then restore Firefox.”<br>
                  <br>
                  <br>
                  The problem: although the new wording is clearer, it
                  still relies on the user to correctly identify which
                  tabs are problematic. So we were wondering whether
                  Firefox can detect these problematic tabs that’s
                  making it crash, then uncheck them automatically.<br>
                  <br>
                  So the instruction (see attached) can say:<br>
                  “We’ve removed the checkmarks in front of the tabs
                  that we think have crashed Firefox”<br>
                  <br>
                </div>
                <div>As an alternative method, maybe we can deselect the
                  last tab containing a web URL that the user has
                  opened, because we assume that it’s almost always
                  going to be the one causing problem.<br>
                  <br>
                  <br>
                </div>
                <div>What do you think?<br>
                </div>
                <div><br>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="m_-2949270695428792543mimeAttachmentHeader"></fieldset>
      <br>
      </div></div><span class=""><pre>______________________________<wbr>_________________
firefox-dev mailing list
<a class="m_-2949270695428792543moz-txt-link-abbreviated" href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a>
<a class="m_-2949270695428792543moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a>
</pre>
    </span></blockquote>
    <p><br>
    </p>
  </div>

</blockquote></div><br></div>