The "search bar" is not visible when dragged from overflow menu and light themes are enabled
Categories
(Firefox :: Toolbars and Customization, defect, P3)
Tracking
()
People
(Reporter: Gabi, Unassigned)
Details
(Keywords: regression)
Attachments
(4 files)
Affected versions
- 66.ob3
- 67.0a1
Affected platforms
- Windows 10x64
- Windows 7x64
Steps to reproduce
- Install Firefox
- Go to Customize
- Drag the "search bar" to the overflow menu
- Drag the "search bar" back
- Observe the search bar colour
Expected result
- Search bar should be more visible when light themes are enabled
Actual result
- The "search bar" is not visible when dragged from overflow menu and light themes are enabled
Regression range
Last good known 2017-08-10
First bad known 2017-08-11
Mozregression did not find any pushlog.
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
|
||
(In reply to Gabi Cheta [:Gabi] Release Desktop QA from comment #0)
Created attachment 9040088 [details]
search.png
This doesn't look like the actual search bar but like the drag image that somehow got stuck.
Reporter | ||
Comment 2•5 years ago
|
||
Reporter | ||
Comment 3•5 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #1)
(In reply to Gabi Cheta [:Gabi] Release Desktop QA from comment #0)
Created attachment 9040088 [details]
search.pngThis doesn't look like the actual search bar but like the drag image that somehow got stuck.
The attachment shows the search bar at the time it was dragged, I attached a gif for better clarity.
Comment 4•5 years ago
|
||
So are you saying the drag image is too faint? I think this looks pretty much as expected.
Reporter | ||
Comment 5•5 years ago
|
||
Reporter | ||
Comment 6•5 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #4)
So are you saying the drag image is too faint? I think this looks pretty much as expected.
Yes, the image was more visible before, see gif recorded with a 57 Nightly build.
Comment hidden (obsolete) |
Comment 8•5 years ago
|
||
(In reply to Gabi Cheta [:Gabi] Release Desktop QA from comment #0)
Regression range
Last good known 2017-08-10
First bad known 2017-08-11
Mozregression did not find any pushlog.
Updated•5 years ago
|
Comment 9•5 years ago
|
||
Is this from https://hg.mozilla.org/mozilla-central/rev/bdc9b689b8b3 ? At a glance, that seems the only related cset, but I wouldn't have expected the fill/stroke changes to make a difference to anything except the icon...
Comment 10•5 years ago
|
||
(In reply to :Gijs (he/him) from comment #9)
Is this from https://hg.mozilla.org/mozilla-central/rev/bdc9b689b8b3 ?
Don't think so.
Comment 11•5 years ago
|
||
I considered marking this a P5, because on the surface this seems pretty cosmetic and polish-y. However, I think there are legitimate accessibility concerns here, where it might not be clear which item is currently being drag/dropped.
So I'm marking this a P3 for now.
Comment 12•5 years ago
|
||
(In reply to Gabi Cheta [:Gabi] Release Desktop QA from comment #6)
(In reply to Dão Gottwald [::dao] from comment #4)
So are you saying the drag image is too faint? I think this looks pretty much as expected.
Yes, the image was more visible before, see gif recorded with a 57 Nightly build.
... but the regression window is a bit weird, because on August 9 builds, I get this, which isn't exactly great either.
(For the avoidance of doubt, the shapeless dark long blob underneath the icons is the dragged search bar)
Comment 13•5 years ago
|
||
Something strange is going on here in graphics/webrender land. Even when I make changes to the CSS for the search bar, the drag shape seems to get misshapen as soon as I actually move the item around. Kats, could you take a look (or redirect to someone who can)?
Comment 14•5 years ago
|
||
To be clear, even with something like:
diff --git a/browser/themes/shared/customizableui/customizeMode.inc.css b/browser/themes/shared/customizableui/customizeMode.inc.css
--- a/browser/themes/shared/customizableui/customizeMode.inc.css
+++ b/browser/themes/shared/customizableui/customizeMode.inc.css
@@ -211,16 +211,22 @@ toolbarpaletteitem[mousedown] > toolbarb
transform: scale(1.3);
}
toolbarpaletteitem[mousedown] > #search-container,
toolbarpaletteitem[mousedown] > toolbaritem.toolbaritem-combined-buttons {
transform: scale(1.1);
}
+/* Make sure the search container looks visible when being dragged */
+toolbarpaletteitem[mousedown] > #search-container > #searchbar > .searchbar-textbox {
+ box-shadow: none;
+ border-color: currentColor;
+}
+
/* Override the toolkit styling for items being dragged over. */
toolbarpaletteitem[place="toolbar"] {
border-left-width: 0;
border-right-width: 0;
margin-right: 0;
margin-left: 0;
}
#widget-overflow-fixed-list > toolbarpaletteitem[place="menu-panel"] {
applied, while I see the extra-dark border when mousedown'ing on the search container, as soon as I move the mouse (with the mouse still down) the border seems to stop painting.
Comment 15•5 years ago
|
||
So I applied your patch (into a new stylesheet via the browser toolbox in a running Nightly) and I see the extra-dark border when I mousedown on the search container in the overflow menu area. And I also see it become very faint as soon as I start moving the mouse. However I see the same with WR enabled and disabled. And I don't see the strange blur mess you posted in attachment 9041428 [details].
I don't know (a) whether this is the system drag and drop or something implemented in the browser front-end, or (b) where that drag image is coming from. I'm think the answer to (a) is that this is the system drag and drop, in which case it's not the Firefox graphics stack that drawing that, it would be the OS. Firefox does provide the drag image to the OS in that case, but I don't think it goes through the compositor pathway - most likely we would use basic layers to render it but that's just a guess.
Do you know where the CSS is that causes that gradient/opacity effect in the first place? (The same effect can be seen if you drag any of the other icons.) I'm wondering if I can fiddle with that to get a clearer understanding of what's going on.
Comment 16•5 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #15)
Do you know where the CSS is that causes that gradient/opacity effect in the first place? (The same effect can be seen if you drag any of the other icons.) I'm wondering if I can fiddle with that to get a clearer understanding of what's going on.
AFAIK Windows applies that effect to any drag image.
Comment 17•5 years ago
|
||
If Windows is applying it then what I'm seeing is expected behaviour. The blurry mess from attachment 9041428 [details] I guess is hardware specific? I would very surprised if that happens with WR enabled but not with WR disabled (or vice-versa).
Comment 18•5 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #17)
If Windows is applying it then what I'm seeing is expected behaviour. The blurry mess from attachment 9041428 [details] I guess is hardware specific?
It's just what I see on an older version, see comment #12.
I'm curious as to how we decide on what drag image to give Windows... who would know?
Comment 19•5 years ago
|
||
(In reply to :Gijs (he/him) from comment #18)
I'm curious as to how we decide on what drag image to give Windows... who would know?
Comment 20•5 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #19)
(In reply to :Gijs (he/him) from comment #18)
I'm curious as to how we decide on what drag image to give Windows... who would know?
Thanks. What I'm confused about is why in some of the earlier builds, the drag image seems to include a gradient / box shadow, but not the (lighter colour) background colour of the textbox. I was wondering if we try and be smart about ignoring the "background" of the element in some way. Or is this just relative dark/lightness confusing my human brain?
Anyway, looks like web authors have this problem, too!
https://stackoverflow.com/questions/18841228/draggable-item-faded-and-ugly
Comment 22•5 years ago
|
||
Gijs, could we restrict the size of the searchbar when dragging (or during mousedown) to something less than 300px wide? Looks like that SO post found that 300px was the cutoff that Windows draws the drag image differently.
Comment 23•5 years ago
|
||
(In reply to Jared Wein [:jaws] (Regression Engineering Owner for 65) (please needinfo? me) from comment #22)
Gijs, could we restrict the size of the searchbar when dragging (or during mousedown) to something less than 300px wide? Looks like that SO post found that 300px was the cutoff that Windows draws the drag image differently.
In principle we could, but different bits of SO / social.microsoft.com also suggest that Windows doesn't take DPI into account when applying this filter, so this would be quite restrictive on screens with high DPI. :-(
I'm tempted to suggest we override the drag image ourselves somehow, though I'm also still looking at how the background colour is taken into account by Windows.
Comment 24•5 years ago
|
||
I'd suggest we wontfix this. It's a Windows design decision to render drag images the way it does, and I can see where they're coming from. The drag image is subtle feedback but doesn't convey anything crucial. Users likely don't need an explicit reminder that they're dragging the search bar.
Comment 25•5 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #24)
I'd suggest we wontfix this. It's a Windows design decision to render drag images the way it does, and I can see where they're coming from. The drag image is subtle feedback but doesn't convey anything crucial. Users likely don't need an explicit reminder that they're dragging the search bar.
This wfm. I looked at windows APIs and the background colour and didn't get anywhere. I played around with making the search bar smaller when dragging it but it's hard/impossible to get it to look right - if there's an animation to make it smaller, it might get dragged before the animation completes (and so it's still the "wrong" size) and if there isn't, it looks like the bar "shoots away" from under the mouse cursor when you mousedown (as it gets smaller). Having it permanently be narrower looks odd in the wide column that is the overflow menu panel.
Note that this also affects drags from the toolbar when the window is wide enough and/or there's enough space there for the search bar to get wider.
Description
•