Closed Bug 1402418 Opened 7 years ago Closed 4 years ago

Invalid url status on url bar after duplicating a tab with middle-click for local svg file

Categories

(Firefox :: Address Bar, defect, P5)

defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr52 --- unaffected
firefox-esr68 --- wontfix
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox76 --- wontfix
firefox77 --- fixed
firefox78 --- fixed

People

(Reporter: fx4waldi, Assigned: pbone)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20170922100051 Steps to reproduce: 1. Open a folder with svg file eg. file:///D:/images/ 2. Go to any svg file eg. file:///D:/images/test.svg 3. Click the middle button on the reload button Actual results: Address of the new tab is invalid (D:\images) Before the url is a glass icon. Star icon isn't displayed. Expected results: The address should be the same as the address of the old tab (file:///D:/images/test.svg) Before the url should be a "i" icon The star and other buttons should be displayed.
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Untriaged → Toolbars and Customization
Ever confirmed: true
Summary: Invalid url bar status after duplicating a tab with local svg file → [Photon] Invalid url status on url bar after duplicating a tab with middle-click for local svg file
Whiteboard: [photon-structure] [triage]
This is unrelated to photon and also reproduces on pre-photon builds, like 56. Still narrowing down a regression window.
Summary: [Photon] Invalid url status on url bar after duplicating a tab with middle-click for local svg file → Invalid url status on url bar after duplicating a tab with middle-click for local svg file
Whiteboard: [photon-structure] [triage]
No longer blocks: photon-structure
I can see a flicker of the magnifying glass but it doesn't stay in this state and the UI is not left in a "broken" state. Tested on Windows with a local SVG file. I tried using mozregression to find when this was "fixed" but testing builds between 2017-09-25 and today shows that this was working as far back as 2017-09-25. Is this still broken for you, fx4waldi?
Flags: needinfo?(fx4waldi)
Yes, the problem still exists. Last good: Version 55.0a1 Build ID 20170321030211 First bad: Version 55.0a1 Build ID 20170322030208
Flags: needinfo?(fx4waldi)
Too late to fix for 58. If someone ends up working on this we are happy to take a patch in Nightly.

This is a URL bar and/or sessionstore and/or tabbed browsing bug, but not toolbars & customization. Unsure why I didn't pick up on that earlier. Anyway, I was reminded of this bug by bug 1571274.

Component: Toolbars and Customization → Address Bar
Priority: P5 → --

Does this still happen?

Flags: needinfo?(fx4waldi)
Priority: -- → P5

No, now it works correctly.

Last bad build: mozilla-central 2019-05-24
First good build: mozilla-central 2019-05-25

Flags: needinfo?(fx4waldi)

(In reply to fx4waldi from comment #7)

No, now it works correctly.

Last bad build: mozilla-central 2019-05-24
First good build: mozilla-central 2019-05-25

This seems to be a race condition. Trying just once on nightly I saw this fixed, but not on beta. Trying repeatedly on nightly, I can still reproduce, even on today's nightly.

(In reply to Drew Willcoxon :adw from comment #6)

Does this still happen?

Is P5 really the best choice for something that causes us to lie in the address bar? Sure, the STR are obscure, but I'm worried that there might be other cases that would also cause this problem, given that we have no idea as to the root cause...

Flags: needinfo?(adw)
Flags: needinfo?(adw)

WFM in current nightly and 77 beta. Based on mozregression, this appears to have been fixed by bug 1597154. \o/

Assignee: nobody → pbone
Status: NEW → RESOLVED
Closed: 4 years ago
Depends on: 1597154
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.