allure-framework / allure-framework/allure3
Reports that share the same origin are interfering with each other
- Dominant language
- HTML
- Stars
- 401
- Forks
- 58
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 34
Description
**Describe the bug**
Multiple Awesome reports hosted on the same origin and opened in separate tabs of the same browser share the state with each other.
This may be useful in certain cases (e.g., to maintain filters and the tree state across the history of the same project). But generally, this is most probably not what users would expect for unrelated reports hosted on the same origin (e.g., in Allure Service).
**To Reproduce**
Steps to reproduce the behavior:
1. Generate multiple Allure Awesome reports.
2. Set up a web server to host both reports.
3. Open both reports in the same browser on separate tabs.
4. Apply some filters for one of the reports.
5. Switch to the second report and reload it: the same set of filters will be applied, even though they were never selected.
**Expected behavior**
All Allure reports must be isolated from each other.
**Screen recording**
https://github.com/user-attachments/assets/06438487-35e9-4d15-b292-d388638b9c72
**Additional context**
The reason this happens is that Allure keeps the report state in local storage, which is shared between the same origin. From :
> The localStorage read-only property of the [window](https://developer.mozilla.org/en-US/docs/Web/API/Window) interface allows you to access a [Storage](https://developer.mozilla.org/en-US/docs/Web/API/Storage) object **for the [Document](https://developer.mozilla.org/en-US/docs/Web/API/Document)'s [origin](https://developer.mozilla.org/en-US/docs/Glossary/Origin)**;
Contributor guide
Research direction
Start by reproducing the two-report scenario in separate browser tabs and inspect the report state stored through the localStorage entry point mentioned in the issue. The work is done when filters and other report state selected in one report no longer appear in an unrelated report on the same origin.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- html
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100