Open Bug 1692679 Opened 3 years ago Updated 4 months ago

Local storage panel is empty

Categories

(DevTools :: Storage Inspector, defect, P3)

Product:
DevTools
Component:
Storage Inspector
Version:
Firefox 85
Type:
defect

Tracking

(Not tracked)

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

  • Save data in localStorage for a website on localhost
  • Open that panel in the F12 tools, select "Local Storage" on the left side
  • See that data
  • Try to delete some or all of it (Result 1)
  • Reload the page (Result 2)
  • Have the page save some data again
  • Restart the browser (Result 3)

Actual results:

Result 1: The data entries sometimes cannot be deleted individually (nothing happens), deleting all works
Result 2: The panel is empty, none of the new data is displayed
Result 3: The newly saved data is visible again

Expected results:

Result 1: Entries should be deletable one by one and the deleted item(s) should immediately disappear from that view
Result 2: The newly data should be visible, i.e. that view should always reflect the current state and even update as soon as some data has been saved or changed
Result 3: OK

The Bugbug bot thinks this bug should belong to the 'Core::Storage: localStorage & sessionStorage' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Storage: localStorage & sessionStorage
Product: Firefox → Core

We might need further investigation to see if it's a LocalStorage issue (e.g. still being able to get the item after the removal), but it looks like there is at least a devtool issue based on comment#0.

If the storage inspector getting the data from the parent process, I would suspect that it's probably related to legacy localStorage implementation. In general, the legacy implementation doesn't update operations to the parent process immediately.

Component: Storage: localStorage & sessionStorage → Storage Inspector
Product: Core → DevTools

Thanks for the report Yves!

I can't reproduce the problem on my machine using your STRs from comment #0

It seems to be working with my STRs:

  1. Load http://odvarko.com/tests/fission/case2/odvarko.com.html
  2. Open DevTools and select the Storage panel
  3. Expand the Local Storage entry in the (left) side panel
  4. Select the http://odvarko.com domain
  5. Click "Add to Local Storage" button on the page
  6. You should see new entries in the Storage panel
  7. Try to delete some of them, they should disappear

Does this work for you?

Honza

Flags: needinfo?(_+bugzilla)

That works, yes. But not my page. I have several of these. You can try this one: https://komprenu.de/kontakt

Enter something in the "Betreff" (subject) field and then the rest of the form automatically appears. If you fill out the message and name, you can see the message "Entwurf gespeichert" (draft saved) next to the blue send button. As you go to other pages (e.g. through the site nav bar at the top) and return to "Kontakt", you'll see your entered data still in the form. That's loaded from localStorage.

Multiple issues here:

  1. Open any other website, like your test page, open that F12 panel. You'll see the original domain there in the list.
  2. Enter the URL shown above into the address bar. The new page loads. Now still the old domain appears in the storage panel. You can reload the page, nothing changes. Switch F12 tabs, nothing. You have to close and reopen the F12 panel to see the correct and current domain. Only then can you continue investigate its data.
  3. Delete all data in that localStorage panel for the domain komprenu.de while the form is loaded and you entered something in it. Now the data is gone. Click on another page. As the contact form is unloaded, it saves its current input again. Now move back to the contact form. You input is still there, so localStorage works as expected. But the storage panel is still empty. You cannot see the data that is accessible to the page to restore the form.
Flags: needinfo?(_+bugzilla)

Thank you for detailed instructions Yves!

(In reply to Yves Goergen from comment #4)

  1. Open any other website, like your test page, open that F12 panel. You'll see the original domain there in the list.

I don't understand what is the issue in this case. What is the difference from #2?

  1. Enter the URL shown above into the address bar. The new page loads. Now still the old domain appears in the storage panel. You can reload the page, nothing changes. Switch F12 tabs, nothing. You have to close and reopen the F12 panel to see the correct and current domain. Only then can you continue investigate its data.

I can't reproduce this, here is what I am doing:

Seems OK for me. Do you have more details?

  1. Delete all data in that localStorage panel for the domain komprenu.de while the form is loaded and you entered something in it. Now the data is gone. Click on another page. As the contact form is unloaded, it saves its current input again. Now move back to the contact form. You input is still there, so localStorage works as expected. But the storage panel is still empty. You cannot see the data that is accessible to the page to restore the form.

I can reproduce this issue.

Honza

Flags: needinfo?(_+bugzilla)

I can't reproduce this, here is what I am doing: (…)

Well, lucky you. My Firefox does something else here. But that's only part of the nuisance, the missing data is more important. I understand that you can confirm that.

Flags: needinfo?(_+bugzilla)

Yes, I can confirm the issue #3 in your list.

Thanks for the help!

Honza

Blocks: 1667980
Severity: -- → S3
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
Priority: -- → P3

Just as a warning: If you need to extract more data from the current web page with the contact form, please do so. That form is due to be updated and might behave a little differently soon (other fields but same draft saving before unload).

Any chance to clone the page and attach it here to this bug?
Having reproducible test case is always very helpful.
Honza

Flags: needinfo?(_+bugzilla)

Sorry, I couldn't find the time to create a copy of that website. The form is still there, it just has one field less. The Firefox bug should still be visible. I'm not sure what the issue is so I can't provide a reduced testcase. At the moment I don't have more resources than reporting this bug.

Flags: needinfo?(_+bugzilla)

I can confirm this bug as well (using Developer Edition v. 87.0b09). Specifically, this is a react/redux application that is setting various values in local storage during the authentication process. Closing and reopening the developer tools will show the local storage, but refreshing the values causes them to disappear. The only way to reliably view what is in local storage is to close and reopen the developer tools window. Only then do the values reflect the current status. Even with this workaround, the "token" value never updates to show the correct value, unless it is set to "". Not sure if it makes a difference, but I'm running Redux DevTools and React Developer Tools (both Firefox Extensions).

This is also present in Firefox 86.0.1

I can confirm this bug using Firefox 87.0 (Ubuntu) for a Vue app using the Vue DevTools. Refresh does not work, right-click to delete does not show updates. Closing and re-opening the dev tools inspector shows the current state. Behavior is identical for cookies and local storage.

Thanks All, for the input.
Any chance to get a stable test case before the original one stops working?
Thank you!
Honza

Flags: needinfo?(kpinkerman)
Flags: needinfo?(jason.kirkpatrick)

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #14)

Thanks All, for the input.
Any chance to get a stable test case before the original one stops working?
Thank you!
Honza

Honza,

I will deploy the site early next week (currently running on localhost) so I can give out the url. Do you have enough information in this thread, or do you need a detailed bug report with it?

Thank you,
Jason

Flags: needinfo?(odvarko)

(In reply to jkirkpatrick from comment #15)

I will deploy the site early next week (currently running on localhost) so I can give out the url.

Perfect, thank you.

Do you have enough information in this thread, or do you need a detailed bug report with it?

Providing the page URL and information how to operate it to reproduce the issue would be great.

Flags: needinfo?(odvarko)

That panel is completely useless now. I've just looked at it and seen a few keys in there for my local host name. Then I've set a new key "dashboard.plot-ep-581.hidden" to the string value "true" through my page and now the panel is empty. Always. I can reload the page as I want, nothing appears in there anymore. But the data is still there, my web app works perfectly.

So, it seems that just setting a key triggers a complete failure of that panel. And the panel wasn't active while I added the key.

Clear needinfos that are pending on inactive users.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Flags: needinfo?(kpinkerman)
Flags: needinfo?(jason.kirkpatrick)
You need to log in before you can comment on or make changes to this bug.