Closed Bug 1253610 Opened 8 years ago Closed 8 years ago

[e10s] Focus rect displays on media element after click

Categories

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

defect

Tracking

()

RESOLVED FIXED
Tracking Status
e10s + ---
firefox47 --- disabled
firefox48 --- fixed

People

(Reporter: Ovidiu, Unassigned)

References

()

Details

(Keywords: regression)

Attachments

(2 files)

Attached image Screen Shot 2016-03-04 at 17.08.46.png (deleted) —
[Affected versions]:

Firefox Nightly 47.0a1 (2016-03-04)

[Affected platforms]:

Tested on Mac OS 10.10, Ubuntu 15.04, Windows 7.

[Steps to reproduce]:

1. Go to  http://people.xiph.org/~giles/2012/opus/
2. Play any of the 2 audio semple 

[Expected result]:

You can't see the dotted border 

[Actual result]:

You can see the dotted border
Only with e10s enabled.
Blocks: e10s
Summary: Borders from the audio samples are visible when you go to http://people.xiph.org/~giles/2012/opus/ → [e10s] Borders from the audio samples are visible when you go to http://people.xiph.org/~giles/2012/opus/
Hi Loic, 

Thank you for testing this, please tell me on what OS you have tested. I have tested with e10s enabled and disabled and I both cases the results are the same.
Flags: needinfo?(epinal99-bugzilla2)
I have some updates regarding this issue. 

It is an e10s issue only on windows OS. Tested again on Windows 7 and 10, and the problem is e10s specific.
On Mac and Ubuntu it's not e10s specific.
Flags: needinfo?(epinal99-bugzilla2)
Does it work with FF44 like Windows on OSX/Linux?
(In reply to Loic from comment #4)
> Does it work with FF44 like Windows on OSX/Linux?

Tested with Firefox 44.0.2 on Windows 10 and I can't reproduce this issue. 
Tested with Firefox 44.0.2 on Mac OS X 10.10 and I can reproduce the issue. 
Tested with Firefox 44.0.2 on Ubuntu 15.04 and I can reproduce the issue.
tracking-e10s: --- → +
Priority: -- → P2
This may be reproducible in non-e10s.
Priority: P2 → --
Summary: [e10s] Borders from the audio samples are visible when you go to http://people.xiph.org/~giles/2012/opus/ → Borders from the audio samples are visible when you go to http://people.xiph.org/~giles/2012/opus/
I have tested on Windows versions and I think this is a e10s specific bug. When e10s is enabled I can reproduce the issue, when e10s is disabled the issue can't be reproduce it. Jimm, on what OS did you test?  I can try to run once again the test.
Flags: needinfo?(jmathies)
(In reply to ovidiu boca[:Ovidiu] from comment #7)
> I have tested on Windows versions and I think this is a e10s specific bug.
> When e10s is enabled I can reproduce the issue, when e10s is disabled the
> issue can't be reproduce it. Jimm, on what OS did you test?  I can try to
> run once again the test.

A couple e10s team members checked osx and linux, and I just checked Windows 7. All reproduce in a non-e10s window.
Flags: needinfo?(jmathies)
(In reply to Jim Mathies [:jimm] from comment #8)
> All reproduce in a non-e10s window.

Drive-by comment: a "non-e10s window" opened while e10s is enabled by default may behave differently from a window opened while e10s is disabled by default. Depending on which you tested you may get different results. I hope it's not relevant here, but APZ in particular will remain enabled in "non-e10s windows" opened while e10s is enabled by default.

I have tested on Windows 10 Pro x64 and Windows 7 Professional x64 and I still can reproduce this issue with e10s enabled, but with e10s disabled I can't reproduce the border. Tested on Nightly 48.0a1(2016-03-09)
none e10s str:

1) click in content
2) type tab until you see a focus rect on the Opus link
3) type tab two more times to bring the focus rect to the audio controls
4) click the audio control play button

You can click the play button first too and then tab to it.

It looks like there are some differences between e10s and non-e10s with focus rect display though. Maybe we can do some testing around that?
Or maybe the focus rect outline was the original bug that was reported here? We triaged this but I'm beginning to think we didn't understand the original report.

Is the bug reported that the dotted line is visible through the play arrow? or is it that the dotted line is visible?
Flags: needinfo?(ovidiu.boca)
Attached video bug recording.mp4 (deleted) —
This are the steps that I performed:

1. Go to  http://people.xiph.org/~giles/2012/opus/
2. Play on one audio sample (you have 2 audio sample).
3. When you press play button you will see a dotted line when e10s is enabled.

I also added a screen recording with the bug, the recording is on Mac. I made it just to see what I am talking about. On Windows with e10s disabled that dotted border is not displayed.
Flags: needinfo?(ovidiu.boca)
Ok so the bug here is that in non-e10s, we don't display the focus rect, in e10s we do.

Neil, anything you can add here? I'm not sure what controls focus rects but we definitely see some differences between e10s and non-e10s.
Flags: needinfo?(enndeakin)
Summary: Borders from the audio samples are visible when you go to http://people.xiph.org/~giles/2012/opus/ → [e10s] Focus rect displays on media element after click
Quite likely to be fixed by 1214293.
Flags: needinfo?(enndeakin)
(In reply to Neil Deakin from comment #15)
> Quite likely to be fixed by 1214293.

I think you meant bug 1174798 which should be coming up in e10s triage this week.
> > Quite likely to be fixed by 1214293.
> 
> I think you meant bug 1174798 which should be coming up in e10s triage this
> week.

No, I meant bug 1214293.
Priority: -- → P2
I tried this on Fx47.0a2 (BuildId: 20160311004048) and win8 with e10s on and I see the dotted border for the rect on which I click play. So basically I cannot repro this bug.
Can someone confirm that this was fixed by 1214293?
Tested on Mac OS 10.10, Ubuntu 14.04, Windows 7 with Firefox Nightly 48.0a1 (2016-03-24) and I can't reproduce it with e10s enabled or disabled. 
 On the same OSs tested with DevelopersEdition 47.0a2 (2016-03-24) and I still can reproduce it with e10s enabled or disabled.

Note: With Nightly is not reproducible.
OK thanks!
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
I investigated this bug and managed to reproduce it in latest Nightly build id: 20160531030258.

I found a regression range : 
Last good revision: 29662e28a9c93ac67ee0b8ddfb65a9f29bbf73f5
First bad revision: 0177462aac74605f426ab9c92e39bb467b7ce2d1

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=29662e28a9c93ac67e
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: FIXED → ---
Yes, this is likely 1263330 and will be fixed by 1174798.
Blocks: 1174798
Based on several comments that this is e10s specific only, this would not be a release blocker for Fx47 as e10s is off by default.
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
I tested again on several OS's with Nightly 50.0a1 (2016-06-10) and here are the results:

Mac OS X 10.10 I can't reproduce this issue with e10s enabled or disabled.

Ubuntu 15.04 I can reproduce this issue with e10s enabled or disabled.

Windows 7 I can reproduce it with e10s enabled and I can't reproduce it with e10s disabled.
You'll need a build with 1174798 fixed to properly verify this.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: