Closed
Bug 1253446
Opened 8 years ago
Closed 8 years ago
Camera indicator is in the wrong position
Categories
(Core :: Widget: Gtk, defect)
Core
Widget: Gtk
Tracking
()
RESOLVED
FIXED
mozilla47
Tracking | Status | |
---|---|---|
firefox47 | --- | fixed |
People
(Reporter: marco, Assigned: jfkthame)
References
Details
(Keywords: regression)
Attachments
(3 files)
236.55 KB,
image/png
|
Details | |
2.00 KB,
patch
|
emk
:
review+
|
Details | Diff | Splinter Review |
934 bytes,
patch
|
emk
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Reporter | ||
Comment 1•8 years ago
|
||
There are actually two regressions, bug 890156 moved it to a wrong position (but at least still visible), bug 1240749 moved it to the current wrong position.
Assignee | ||
Comment 2•8 years ago
|
||
Hmm - what exactly is this "camera indicator"? I'm not familiar with it at all. Is this a Linux-specific UI element, or should I be seeing something similar on other platforms?
Reporter | ||
Comment 3•8 years ago
|
||
It's the indicator that a camera is being used by a webpage. You can see it if you accept the getUserMedia prompt, e.g. on this page: http://mdn-samples.mozilla.org/s/webrtc-capturestill/.
Assignee | ||
Comment 4•8 years ago
|
||
Yeah, I figured that's what it means, but I hadn't ever seen (noticed) it before. Just checked on OS X, and here we add an icon to the system menubar, so that must be a quite separate, system-specific implementation. Just tried on Windows, too, and I see we do have the same indicator as Linux -- and a similar problem with its position. Though even Firefox 44 mispositioned it for me on Windows when I tried with a multi-monitor configuration, though not as badly as Nightly. Do you happen to know what this thing is called in the Firefox code, or where it's implemented?
Reporter | ||
Comment 5•8 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #4) > Just tried on Windows, too, and I see we do have the same indicator as Linux > -- and a similar problem with its position. Though even Firefox 44 > mispositioned it for me on Windows when I tried with a multi-monitor > configuration, though not as badly as Nightly. I'm currently using a single monitor, can you reproduce it if you use a single monitor? > Do you happen to know what this thing is called in the Firefox code, or > where it's implemented? I'm not sure, maybe somewhere in this file: http://mxr.mozilla.org/mozilla-central/source/browser/modules/webrtcUI.jsm.
Assignee | ||
Comment 6•8 years ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #5) > (In reply to Jonathan Kew (:jfkthame) from comment #4) > > Just tried on Windows, too, and I see we do have the same indicator as Linux > > -- and a similar problem with its position. Though even Firefox 44 > > mispositioned it for me on Windows when I tried with a multi-monitor > > configuration, though not as badly as Nightly. > > I'm currently using a single monitor, can you reproduce it if you use a > single monitor? Yes, if the dpi scaling is > 100%. (With Nightly, that is; release Firefox handles it OK in this case.) > > > Do you happen to know what this thing is called in the Firefox code, or > > where it's implemented? > > I'm not sure, maybe somewhere in this file: > http://mxr.mozilla.org/mozilla-central/source/browser/modules/webrtcUI.jsm. Thanks, that helps. Specifically, it looks like the code in browser/base/content/webrtcIndicator.js is responsible for positioning it; I'll see if I can figure out where the confusion is coming from.
Assignee | ||
Comment 7•8 years ago
|
||
The problem here is that the webrtcIndicator code doesn't convert between desktop pixels (from the nsIScreen APIs) and CSS pixels; and since landing per-monitor DPI support, these are no longer equivalent, as they used to be (on Linux and Windows). So a bit more care is needed in this code.
Attachment #8726774 -
Flags: review?(VYV03354)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•8 years ago
|
||
On Windows, there's a secondary problem as well, which is that defaultCSSScaleFactor fails to return the correct value when called on primaryScreen. This is because for primaryScreen, the code just uses a null HMONITOR, but handing that to WinUtils::LogToPhysFactor doesn't work. With this fixed, I'm now seeing the webrtc indicator positioned correctly on Windows.
Attachment #8726783 -
Flags: review?(VYV03354)
Assignee | ||
Comment 9•8 years ago
|
||
Try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ed9a096ef848
Updated•8 years ago
|
Attachment #8726774 -
Flags: review?(VYV03354) → review+
Updated•8 years ago
|
Attachment #8726783 -
Flags: review?(VYV03354) → review+
Assignee | ||
Comment 10•8 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/2a06c1a146e16a369ab3648e184d9e3311362395 Bug 1253446 - patch 1 - Convert from device to CSS pixels when positioning the webrtc indicator. r=emk https://hg.mozilla.org/integration/mozilla-inbound/rev/431e74ed28d9ebbbe01ed7278efa79b6dd8db5aa Bug 1253446 - patch 2 - Return the proper scaling factor when querying the primary screen on Windows. r=emk
Comment 11•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2a06c1a146e1 https://hg.mozilla.org/mozilla-central/rev/431e74ed28d9
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
You need to log in
before you can comment on or make changes to this bug.
Description
•