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.

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

For more information, please visit auto_nag documentation.

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

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?

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.

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.