Bug 1214644 - firefox loses ipv4 when returning from hibernation
Summary: firefox loses ipv4 when returning from hibernation
Status: RESOLVED DUPLICATE of bug 1204057
Alias: None
Product: openSUSE Distribution
Classification: openSUSE
Component: Firefox (show other bugs)
Version: Leap 15.5
Hardware: x86-64 openSUSE Leap 15.5
: P5 - None : Major (vote)
Target Milestone: ---
Assignee: Factory Mozilla
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-08-26 10:31 UTC by andreas bittner
Modified: 2023-08-26 13:07 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description andreas bittner 2023-08-26 10:31:00 UTC
same bug on 15.4 back then but nobody? ever answered there:

https://bugzilla.opensuse.org/show_bug.cgi?id=1204057

some recent hp probook with 15.5 x64, doing hibernation very rarely.
but when coming back from hibernation apparently the whole restored system with the firefox 115 in it running, can not make use of ipv4 any more. completely losing its ipv4 functionality.

i can see ctrl+shift+i in firefox and trying to load ipv4 pages or mixed content URLs observing that all sub URIs hostnames etc, that only resolve to ipv4 show failing log lines as:

nss unknown address or something mozilla networking stack or so, sorry didnt copy/paste.


at the same time I can happily nslookup, host or resolve in general in a Konsole window these addresses to ipv4 normally.

also turning wifi off/on doesnt help firefox at all. also inside firefox file menu, work offline and coming back online doesnt help either.

only a complete shut down of firefox, firefox restart does normalize the situation again.

an installed google chromium, brave or other browsers dont have trouble reaching the webpages or mixed ip stack content.

can anyone take a look at this how to proceed? thanks.
Comment 1 Andreas Stieger 2023-08-26 13:07:17 UTC
resolving as duplicate to previous report

*** This bug has been marked as a duplicate of bug 1204057 ***