Network Monitor -> open New Tab for File results in a new Session
Categories
(DevTools :: Netmonitor, defect, P3)
Tracking
(Not tracked)
People
(Reporter: simon.agostini, Unassigned)
Details
Attachments
(4 files, 1 obsolete file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.164 Safari/537.36
Steps to reproduce:
Open Developer Tools via F12.
Load a page and check the files under Networkmonitor.
Check PHP session cookie of a file.
Right click that file and select open in new tab.
Check Session of newly opened tab (via F12)
Actual results:
Newly opened tab (Tab 2 ) got a new Session ID and invalidates session from Tab 1
Expected results:
Session shall be kept the same as in Tab 1, so no new Session shall be generated.
Comment 1•4 years ago
|
||
Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.
Comment 2•4 years ago
|
||
I don't have access to a PHP website on which I could log at the moment, but I checked on bugzilla (the cookie is named Bugzilla_logincookie), and opening a document in a new tab from the netmonitor still keep the cookie value.
Could you point us to a specific page/url where we can reproduce your issue? Thanks
Sorry I cannot share the URL since it is a internal project.
But I found out that if I open a new tab from the Dev Tools in is missing the Request cookie and it overrides the already available cookie with the new Session id and therefore it looses it s context.
This only happens in Firefox Developer, not seen on other Browsers like Chrome etc.
Updated•4 years ago
|
Comment 4•4 years ago
|
||
I tried to reproduce this issue, but no luck
Here is what I tried:
- Load http://janodvarko.cz/tests/bugzilla/1721786/
This page is implemented in PHP and prints out value of "Bug1721786Cookie" request cookie
The cookie is created in the page as well so, the first load should show an empty value
(the source of the page is attached) - Open DevTools, select the Network panel and reload the page
- Inspect request cookies, you should see "Bug1721786Cookie"
- Right click on the "tests/bugzilla/1721786/" reuqest and pick "Open in New Tab"
- You can see that the new tab also shows - Request cookie "Bug1721786Cookie" has value: "a value"
DevTools are not automatically opened for the new tab so, that's why the page prints the request cookie by itself.
Not sure if this are the right steps to reproduce the reported issue. But, does this work for you?
Should I try different steps? If yes, what exactly?
Thank you!
Honza
Hello,
I can see the cookie as you describe it.
But in your example Page I cannot see the PHPSESSID cookie which I have.
Can you enable PHP as session cookie based version?
Also the samesite attributes etc. are missing for me.
Maybe there is a issue? Just wondering why it worked flawless with older Firefox Versions.
Updated•4 years ago
|
Comment 6•4 years ago
|
||
I extended the test case with PHPSESSIONID cookie. When following my steps from comment #4 I can see it in another tab too.
Can you please try it on your machine, thank you!
Hi,
I have tested you example again with same result cookie stays the same but I saw your webserver does not respond as mine.
Yours does not set a cookie as Response (as I can see).
Comment 9•4 years ago
|
||
Can you please share your test case, so we can try it and reproduce the bug on our machines?
| Reporter | ||
Comment 10•4 years ago
|
||
I cannot share my embedded system.
But we use lighttpd 1.4.59 as webserver running with PHP 7.3.26 with HTTPS
Cookie related settings in the php.ini are:
"
session.name = PHPSESSID
session.use_cookies = 1
session.cookie_secure = 1
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly = 1
session.cookie_samesite="Strict"
session.serialize_handler = php
"
Comment 11•4 years ago
|
||
Unreproducible so far, we can update the priority and severity once we have other STRs.
Comment 12•4 years ago
|
||
There is a phpMyAdmin issue that looks like it is related to this bug.
Updated•2 years ago
|
Description
•