Open Bug 1651379 Opened 4 years ago Updated 3 years ago

If clicking a link causes it to disappear, the URL in the corner of the screen doesn't disappear

Categories

(Core :: DOM: Core & HTML, defect, P3)

79 Branch
Desktop
All
defect

Tracking

()

Tracking Status
firefox78 --- affected
firefox79 --- affected
firefox80 --- affected

People

(Reporter: vaindil, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

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

Steps to reproduce:

Find a URL that disappears when clicked and click it.

Actual results:

The text in the bottom corner of the browser window with the URL should disappear as well.

Expected results:

The URL text stays open until another link is hovered over. This happens across a few sites, most notably old reddit (see gif) and Discord, but I haven't been able to come up with a simple reproduction that always triggers it. (The issue on old reddit in the gif does reproduce it 100% of the time, but a link on its own on an otherwise blank page doesn't exhibit the problem.)

Hi,

I can also reproduce and see the void operator text at the bottom on my end as well, until hovering over another link.

I've tested this on windows 10 pro, 80.0a1 (2020-07-13) (64-bit), Release 78.0 (64-bit and Beta 79.0b5 (64-bit)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/void

Here's the link I used to reproduce: https://old.reddit.com/r/AskReddit/comments/hq6dys/whats_a_dark_secretquestionable_practice_in_your/

I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Best regards, Clara.

Status: UNCONFIRMED → NEW
Component: Untriaged → DOM: UI Events & Focus Handling
Ever confirmed: true
Product: Firefox → Core
Component: DOM: UI Events & Focus Handling → General
Product: Core → Firefox
Component: General → Tabbed Browser

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)

The UI depends on nsIXULBrowserWindow::setOverLink being called (via nsDocShell::OnLeaveLink).

Component: Tabbed Browser → DOM: Core & HTML
Flags: needinfo?(dao+bmo)
Product: Firefox → Core

When EventStateManager::ContentRemoved() is never called with <a> element, but EventStateManager checks whether the removing content is an <a> element before checking Element::LeaveLink(). In the link of comment 1, <a> element is removed by removing its ancestor <div> element. So, perhaps, the anchor element notified DocShell should be stored anywhere, and it should be handled in EventStateManager::ContentRemoved() when its ancestor is removed. WDYT, smaug?

Flags: needinfo?(bugs)
See Also: → 1239048

Ah yes, bug 647665 didn't fix this for descendants of the removed element.
I guess EventStateManager::ContentRemoved should in general go through all the descendants.

It might be nice if UnbindFromTree could do this all, but that might be too late, since ContentRemoved is called just before UnbindFromTree.

Flags: needinfo?(bugs)

I think that this is a bug of the looks, i.e., I mean that this does not cause any security issue sot that I give normal priority to this bug.

Severity: -- → S3
OS: Unspecified → All
Priority: -- → P3
Hardware: Unspecified → Desktop
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: