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)
Core
Layout: Block and Inline
Tracking
()
RESOLVED
FIXED
People
(Reporter: Ovidiu, Unassigned)
References
()
Details
(Keywords: regression)
Attachments
(2 files)
[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/
Reporter | ||
Comment 2•8 years ago
|
||
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)
Reporter | ||
Comment 3•8 years ago
|
||
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)
Reporter | ||
Comment 5•8 years ago
|
||
(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.
Updated•8 years ago
|
tracking-e10s:
--- → +
Priority: -- → P2
Comment 6•8 years ago
|
||
This may be reproducible in non-e10s.
Updated•8 years ago
|
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/
Reporter | ||
Comment 7•8 years ago
|
||
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)
Comment 8•8 years ago
|
||
(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)
Comment 9•8 years ago
|
||
(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.
Reporter | ||
Comment 10•8 years ago
|
||
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)
Comment 11•8 years ago
|
||
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?
Comment 12•8 years ago
|
||
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)
Updated•8 years ago
|
Reporter | ||
Comment 13•8 years ago
|
||
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)
Comment 14•8 years ago
|
||
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
Updated•8 years ago
|
Comment 16•8 years ago
|
||
(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.
Comment 17•8 years ago
|
||
> > 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.
Updated•8 years ago
|
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.
Comment 20•8 years ago
|
||
Can someone confirm that this was fixed by 1214293?
Reporter | ||
Comment 21•8 years ago
|
||
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.
status-firefox48:
--- → fixed
Comment 23•8 years ago
|
||
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
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.
Updated•8 years ago
|
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 26•8 years ago
|
||
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.
Comment 27•8 years ago
|
||
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.
Description
•