User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20171203100121 Steps to reproduce: On Version 59.0a1 2017-12-03 64-bit Nightly -- Created Addon action to: 1) Create a new Tab 2) Discard the new Tab immediately The desire here is to create a new tab but not load it's contents. I believe the 'tabs.discarded' option is under consideration for 'tabs.create()' which would perform this function. However, the bug I'm reporting here is still a problem. Actual results: The Tab appears in the Tabbar, but cannot be activated. Clicking on the Tab shows a blank page, and Right-Click / Reload does nothing. The Tab must be deleted. Expected results: When Clicked, the Tab should finish loading, and When Right-Click / Reload, the Tab should re-load.

It appears that if a new tab gets created, but never gets activated at any point in time, then is discarded, this problem will occur. Regarding bug 1378647, this should create the tab in the lazy state in the first place (if done correctly IMO), and thus would not be dealing with this issue.

I wonder whether this is the desktop equivalent of bug 1229259, i.e. we need the session store data to restore a discarded tab, but there's a certain window of time where a freshly created tab won't yet have any session store data.

Tab is "dead" from the start. Empty without correct title and without icon. Reloading does nothing. It's dead.

Test case, try this code: browser.tabs.create({ url: 'https://mozilla.org', active: false}).then(tab => browser.tabs.discard(tab.id))

(In reply to hifromnz from comment #5) > Um... Mozilla - what happened to "open source"...? You seem to have locked > out basic add-ons from essential functionality=ability to restore sessions > properly? We users are getting pretty sick of broken firefox addons because > you are not providing them with what they need. Let them use your session > manager PLEASE. Don't force them to reinvent the wheel. Hi there, hifromnz. Not sure if you intended to do this but you posted this exacty comment in three different bugs, all of which had either been approved or assigned for further investigation. In the future, please refrain from posting the same comment in multiple bugs and and be sure to read the Bugzilla Etiquette Guide before commenting. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

In this bug I am going to prevent discard if the tab is not ready for it. Bug 1378647 should address the use case being attempted here.

> In this bug I am going to prevent discard if the tab is not ready for it. Blocking entirely or delaying till tab has "complete" status? For example a loop with interval with a status check would probably solve the problem.

Or actually...bug 1446426

(In reply to kroppy from comment #9) > > In this bug I am going to prevent discard if the tab is not ready for it. > Blocking entirely or delaying till tab has "complete" status? For example a > loop with interval with a status check would probably solve the problem. Blocking the ability to discard until the session state has been set during tab creation.

So it's on our hands to check first if tab has completed loading? I saw you just added "return" there. Maybe someone can add a note in docs, before people get mad why discard is not working? Anyway a proper way must be done => (Bug 1378647).

Comment on attachment 8979394 [details] Bug 1422588 fix discard if tab sessionstate is not ready, https://reviewboard.mozilla.org/r/245556/#review251762

After investigating the test failures with this, I see that this approach will probably not work. I'm not certain why it passes in some cases, but it definitely fails consistently on windows. We get an empty entries array in some valid cases. ISTM that we need to do something similar to SessionStore.duplicateTab, specifically the parts around getting/flushing state. We would need to call this from tabbrowser.discardBrowser. Mike, Dao, any thoughts on that approach?

Sounds about right, except that SessionStore.resetBrowserToLazyState should probably be responsible for this, not tabbrowser.js.

Flushing state did nothing. After tracing all this through, what I see is that there is no cache data. Setting that in this instance fixed this particular issue.

Comment on attachment 8979394 [details] Bug 1422588 fix discard if tab sessionstate is not ready, https://reviewboard.mozilla.org/r/245556/#review257380 LGTM, thanks for taking a look at this!

Pushed by mixedpuppy@gmail.com: https://hg.mozilla.org/integration/autoland/rev/645e1b5b6470 fix discard if tab sessionstate is not ready, r=Gijs,mikedeboer

Shane - there is another similar bug: Bug 1378647. Can you look into it? Thanks!!

(In reply to Robert Ab from comment #23) > Shane - there is another similar bug: Bug 1378647. Can you look into it? > Thanks!! The right way to ask is to ni? me on that bug rather than a closed bug. I've already been on it for some time.