Closed Bug 1301631 Opened 8 years ago Closed 8 years ago

[e10s] Focused anchor link (<a>) on parent tab doesn't have dotted outline around it after switching back from the child tab

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Version:
48 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1055751
Tracking Flags:
Tracking Status
e10s ? ---
firefox48 --- affected
firefox49 --- affected
firefox50 --- affected
firefox51 --- affected

People

(Reporter: come, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160823121617

Steps to reproduce:

I manually enabled Electrolysis in about:config with browser.tabs.remote.force-enable to true.


Actual results:

Since then there is no more link dotted outline when I open a link in a new tab, go to the new tab, and go back to the previous tab. This is a useful feature on pages with a lot a links to remember the last link opened.


Expected results:

There should be the link dotted outline when I open a link in a new tab, go to the new tab, then go back to the previous tab.
Blocks: e10s
tracking-e10s: --- → ?
Component: Untriaged → Layout: Block and Inline
Product: Firefox → Core
Summary: No more link dotted outline with Electrolysis enable → [e10s] Anchor links (<a>'s) don't have a dotted outline around them when they become "active" or "focused"
Ok, it's a specific case here.

STR:
1) Load a webpage with anchors links
2) Click immediately on a link with the mouse wheel
3) Go to the child tab
4) Go back to the parent tab

Result: focused anchor link on parent tab doesn't show dotted outline.
Summary: [e10s] Anchor links (<a>'s) don't have a dotted outline around them when they become "active" or "focused" → [e10s] Focused anchor link (<a>) on parent tab doesn't have dotted outline around it after switching back from the child tab
Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=dbb4b83be583eacc401648c5c33091958c29c4c3&tochange=e7a3ba795e1a1f0547505e2c240baef183243fd3

Bug 1174798 landed only in FF50+ and FF48 has the bug, so I'd say the culprit is the restricted bug:
Neil Deakin — Bug 1276976, ensure that popups are visible in the right area, r=tn, r=mrbkap
which has been probably backported from 50 to 48.
Blocks: 1174798
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
tracking-firefox49: --- → ?
tracking-firefox50: --- → ?
tracking-firefox51: --- → ?
Ever confirmed: true
Flags: needinfo?(enndeakin)
Keywords: regression
Not a regression. Duplicate of 1055751.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(enndeakin)
Keywords: regression
Resolution: --- → DUPLICATE
No longer blocks: 1174798
It worked previously on Windows with e10s enabled before your patches, so something has been changed.
bug 1055751 is about the same issue, but on OSX.
It hasn't since the code that does this is disabled in e10s. What changed is that proper determination of whether focus rings should be displayed or not was broken entirely until 1174798 was fixed. So it might appear to have worked, but may not have done.
Adjusting tracking flags. The dupe tracks the e10s part.
tracking-firefox49: ? → ---
tracking-firefox50: ? → ---
tracking-firefox51: ? → ---
You need to log in before you can comment on or make changes to this bug.