Closed Bug 862209 Opened 11 years ago Closed 11 years ago

Defect: Unloaded websites reloading after closing them while using "tabs from last time"

Categories

(Firefox for Metro Graveyard :: Shell, defect)

x86_64
Windows 8.1
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: kjozwiak, Unassigned)

Details

Attachments

(1 file)

"Unloaded" tabs that appear "white" in the "Tab App Bar" are re-loaded into Firefox Metro despite being closed when "tabs from last time" is selected under "Options"

Steps to reproduce the issue:

1) Open Firefox Metro
2) Go into the "Settings" charm and select "tabs from last time" from "Options"
3) Open three different tabs (Twitter, Facebook, CNN)
4) Once all the tabs are opened, close Firefox Metro by sliding the window to the bottom of the screen
5) Repeat Step #1
6) Two of the three tabs will be "unloaded" and appear as "white" in the "Tab App Bar"
7) Close one of the "unloaded" tabs using the "X" in the "Tab App Bar"
8) Close Firefox Metro
9) Repeat Step #1 (You will notice that once you reopen Firefox Metro again, the tab that you closed re-appears despite the user closing it)

Current Behavior:

- "Unloaded" websites are reloaded into Firefox Metro after they have been closed when re-opening Firefox Metro

Expected Behavior:

- Once you close a tab, it should stay closed despite its state when you re-open Firefox Metro and have "tabs from last time" selected
Nice find, for what it's worth I hate this tabs on demand feature. I can see not loading them at startup, but I think the tabs should eventually be loaded on both Metro and Desktop.
We should absolutely change that tabs on demand pref for Metro. If we offer "remember" as a v1 feature, we have to load the background tabs. If we don't get that, I'd prefer we drop the feature for v1 and come back  at it for v2.
Blocks: metrov1it7
No longer blocks: metrov1defect&change
Assignee: nobody → ally
QA Contact: jbecerra
Whiteboard: feature=defect c=Content_features u=metro_firefox_user p=0 → feature=defect c=Content_features u=metro_firefox_user p=1
Priority: -- → P1
Status: NEW → ASSIGNED
Attached patch pref changeSplinter Review
This is the pref change, *but* try as I might I can't get steps 6 or step 9 in the str to reproduce either in -metrodesktop or in immersive, so I can't say whether or not this fixed it. :(

Jim, Brian, Kamil, any insights?
are you sure this option is set?

> "tabs from last time" from "Options"

Maybe you closed via the application list on the left edge of the screen (via right click/close) after changing the option and then the options didn't save? (There's a different bug filed for that).

I reproduced this just after Kamil posted a couple weeks ago but haven't retried since then.
Comment on attachment 743921 [details] [diff] [review]
pref change

I can't reproduce the str, but with bbondy's help, I'm reasonably convinced that the feature is disabled when the pref is flipped. I guess there's nothing else to do here? Over to review it goes.
Attachment #743921 - Flags: review?(netzen)
Comment on attachment 743921 [details] [diff] [review]
pref change

Review of attachment 743921 [details] [diff] [review]:
-----------------------------------------------------------------

Hey Ally, I tried this pref change locally but unfortunately the problem isn't fixed for me. 
Here's how I reproduced (in the immersive environment):
1. Set the restore tabs from last time option
2. Close via drag Metro browser down from top to bottom of screen
3. re-opened metro firefox.
4. Opened 3 tabs with different urls loaded.
5. Closed via drag Metro browser down from top to bottom of screen
6. re-opened metro firefox, note 3 tabs are loaded
7. Opened the tab bar and closed 2 of the sites without switching to them.
8. Closed via drag Metro browser down from top to bottom of screen
9. Opened

At 9 I expected to see only 1 tab left over, but all 3 were left over.  The pref change seemed to have no effect.
Attachment #743921 - Flags: review?(netzen)
n(In reply to Brian R. Bondy [:bbondy] from comment #8)
> Comment on attachment 743921 [details] [diff] [review]
> pref change

> At 9 I expected to see only 1 tab left over, but all 3 were left over.  The
> pref change seemed to have no effect.

Try as I might, I cannot get this to reproduce on my vaio. >.< Meeting with Kamil tomorrow via the interwebs to try and shake this out.
I'm using a vaio too by the way, strange. What do you see at step 9?  Only 1 tab left over? You aren't switching to the tabs before closing them right?
(In reply to Brian R. Bondy [:bbondy] from comment #10)
> I'm using a vaio too by the way, strange. What do you see at step 9?  Only 1
> tab left over? You aren't switching to the tabs before closing them right?

Yea, just one, and I'm not switching tabs to close them. Kamil patiently went over it with me and the steps match (I was hoping I was doing something wrong).

The best guess I got is that I have a local build & he has one from the nightly ftp server, and some how that's messing with things.
I got it to work on today's m-c! I am delighted.
The pref applies, but does not fix the issue. Something else is going on.

p=5?
Whiteboard: feature=defect c=Content_features u=metro_firefox_user p=1 → feature=defect c=Content_features u=metro_firefox_user p=5
...I could reproduce this on m-c last night, but after my morning pull today, I no longer can. Can those of you (Kamil, bbondy) who had reliable reproductions see if you can?
Flags: needinfo?(netzen)
Hey Ally,

I can still reproduce it with today's Nightly build.  I'd recommend just getting Marco to remove this from this iteration and then someone can take it on a later iteration that can reproduce it.  I think we could lower the point value too if someone who can reproduce it works on it. Fixing something that you can't reproduce consistently is way harder as you know :)
Flags: needinfo?(netzen)
Assignee: ally → netzen
We're removing this option in bug 872096, so I'm moving this to v2.
In v2 we can work on this if we decide to re-introduce the option.
Assignee: netzen → nobody
Depends on: metrov2planning
Whiteboard: feature=defect c=Content_features u=metro_firefox_user p=5 → feature=defect c=Content_features u=metro_firefox_user p=0
Blocks: metrov2planning
No longer blocks: metrov1it7
No longer depends on: metrov2planning
No longer blocks: 801199
QA Contact: jbecerra
This bug is still happening even with the "always show tabs" being removed. Simply enabling "tabs from last time" and then following the steps in Comment 0 will reproduce the issue. 

If you close a tab and then close Firefox Metro by sliding it to the bottom, re-opening the browser will have all the tabs opened including the one closed.
Thanks Kamil, moving this back to v1triage based on the info in Comment 17. We moved it in Comment 16 because we thought it would go away anyway, but it hasn't.
Blocks: metrov1triage
No longer blocks: metrov2planning
Blocks: metrov1defect&change
No longer blocks: metrov1triage
Priority: P1 → P2
Status: ASSIGNED → NEW
Showing tabs from last time is not a user story we agreed to support in V1.  It's buggy and I recommend it be removed from v1. That would make this V2 material.
Priority: P2 → --
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
No longer blocks: metrov2defect&change
Whiteboard: feature=defect c=Content_features u=metro_firefox_user p=0
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: