HSL tab in 0.92 corrupted: colors in hue slider incorrect, defunct 5th slider at the bottom

Bug #1635982 reported by Brynn
60
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Medium
shark0r
0.92.x
Fix Released
Medium
shark0r

Bug Description

Hi Friends,
Just came across this problem in 0.92pre2(beta) and was advised via user mailing list to submit a report. Please let me know what all kind of files or logs or screenshots you might need. I'll attach one screenshot.

version 0.92pre2(beta) 64-bit exe installer (from https://inkscape.org/gallery/item/10169/)

This is on Windows 7, sp1, 64-bit

Here's how I can reproduce it:

1 - draw 2 objects
2 - fill one with a solid fill
3 - fill the other with a gradient
4 - select the solid fill object and switch to HSL tab, to see the erroneous appearance, like in attached screenshot

Note that as long as a file containing a gradient is already open, any new object with a solid fill, or any new file in which an object with a solid fill is drawn, will give this appearance on the HSL tab. The other 4 tabs in the Fill and Stroke dialog are not affected. Only HSL tab.

Revision history for this message
Brynn (brynn4inks-deactivatedaccount) wrote :

Oop, I must have clicked submit instead of extra options. Here comes the screenshot.

Revision history for this message
Brynn (brynn4inks-deactivatedaccount) wrote :

This apparently affects the HSL tab, wherever it might be. For example, I just saw it in Extensions > Raster > Colorize

jazzynico (jazzynico)
tags: added: color ui
Revision history for this message
jazzynico (jazzynico) wrote :

Not reproduced on Windows XP (32-bit), lp:inkscape/0.92.x rev. 15141.
Not reproduced on Xubuntu 16.04 (64-bit), lp:inkscape/0.92.x rev. 15141 and lp:inkscape rev. 15196.

Could you please attach an example SVG file so that we can try to reproduce?
Thanks!

Changed in inkscape:
status: New → Incomplete
Revision history for this message
Brynn (brynn4inks-deactivatedaccount) wrote :

As I was making a test file, I discovered that it might not be the gradient which triggers it. In this test file, a simple blur causes it to happen. testHSL092a.svg

Hhm, after further testing, the problem happens with neither blur nor gradient in the file. See testHSL092b.svg where I see the erroneous display with simple fills.

Thanks,
brynn

Revision history for this message
Brynn (brynn4inks-deactivatedaccount) wrote :

next attachment

jazzynico (jazzynico)
Changed in inkscape:
status: Incomplete → New
Revision history for this message
jazzynico (jazzynico) wrote :

Thanks for the test files!
Unfortunately, I still can't reproduce the bug. Probably a win64 only issue.

Revision history for this message
Hachmann (marenhachmann) wrote :

No, it happened to me, too.

Revision history for this message
Hachmann (marenhachmann) wrote :

(but on trunk, a couple of weeks ago. Didn't notice it recently in 0.92pre from Oct 31st)

Revision history for this message
Brynn (brynn4inks-deactivatedaccount) wrote :

Martin (doctormo) reported seeing it too, and I think he's a Ubuntu user.

Guess we need to collect more data...

Revision history for this message
Duarte Ramos (duarte-framos) wrote :

I can confirm this under Windows 7 64bits too, both for 0.92 pre 2 and the recently released pre 3

Not really sure what triggers it, but the HSL hue slider becomes 'corrupted' whowing wrong colors, and an additional label-less color slider becomes visible.

using gradients certainly seems to trigger it, some times clicking a gradient stops also makes the hue slider appear regular for a bit, but then it goes back to being corrupted.

jazzynico (jazzynico)
Changed in inkscape:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Hachmann (marenhachmann) wrote :

Got it, too, yesterday on pre5 on Linux Mint 18, when selecting multiple mesh nodes with the fill and stroke dialog open. It didn't happen every time, though, but at least every 4th time.

I can confirm Duarte's findings:
There is one additional slider at the bottom, which doesn't do anything.
And the slider at the top doesn't show the correct color scale, but otherwise works correctly.

Revision history for this message
Frank Rysanek (frr) wrote :

This bug happens to me in quite a stubborn/reliable fashion, in 0.92-RELEASE.

My environment: Win7 Pro SP1 64b CZ on a low-end Broadwell-based Lenovo Ideapad. I downloaded the 64bit MSI installer of 0.92 shortly after release announcement, with a hope that I'd get rid of some slightly annoying bugs of 0.91 (which I had to manually uninstall first).

The reproduction method seems to work best if Inkscape remembers the "fill+stroke" dialog open, hence the first step.
1) start Inkscape, open the "fill+stroke" dialog (you may need to draw some misc object to do that, not sure) and close Inkscape without saving, while leaving the "fill+stroke" dialog open.
2) start Inkscape. A default empty document will open, and the "fill+stroke" dialog will automatically open too, on Inkscape startup. You don't need to save it, but the bug appears just the same if you do save the empty drawing first.
3) draw an elipse or a rectangle. The "fill+stroke" dialog will immediately focus on the object just created. Switch to the "fill" tab and click the HSL button (to select this color model). The HSL color selector looks allright now.
4) in the main toolbar, switch to the "select" tool (basic arrow cursor) and click the mouse away from the object just created, to make the object lose focus.
5) click the object just created, to make it re-gain focus. The fill+stroke dialog re-activates automatically and is now bonkers. If you click away from the object and click it again, the fill+stroke dialog is still bonkers. And will stay bonkers on any further attempt (click away, click your object).

Others have already described what "bonkers" means: the "hue" scroll bar shows an incorrect gradient (something blending into the alpha checkerboard, rather than the rainbow palette of fully saturated colors), the H S L A labels are missing and there's a fifth scroll bar with no obvious purpose.

If you start Inkscape with the "fill+stroke" dialog closed, and you start from there (draw some rectangle or elipse, open "fill+stroke" etc.), it takes maybe 4 attempts at "click away and click the object again" to get the HSL dialog to lose sanity.

If you follow my reproduction method (start with the "fill+stroke" dialog open as remembered from a previous session), you can get the HSL dialog back in shape by deleting the object, and creating another one. Once the object is created anew, the HSL dialog is okay at first. But click away and click the object again, and bingo, HSL is again bonkers :-)

To me, this bug is pretty much a show-stopper. I'm gonna have to revert to 0.91 to get some work done :-( In my illustrations, I tend to use pale fill colors to distinguish some property of the objects depicted, and I love duplicating an existing object and just shifting the hue slider to modify the tinge, while keeping the saturation and lightness. It allows me to maintain a certain "color style"...

Revision history for this message
jazzynico (jazzynico) wrote :

Just reproduced (at last!) on Xubuntu 16.04, with lp:inkscape/0.92.x rev. 15315.

Not too severe for me. It takes tens of tries before managing to reproduce the issue. Clicking away clears the dialog and the buggy bars don't show the next time an object is selected, so it's a minor annoyance on Xubuntu. Anyway, it confirms the issue is in our code (or a dependency) and affects all operating systems.

Changed in inkscape:
status: Confirmed → Triaged
Revision history for this message
jazzynico (jazzynico) wrote :

@Brynn, Duarte, Franck - could you please confirm that the issue is new in 0.92 and doesn't affect 0.91?

Revision history for this message
su_v (suv-lp) wrote :

As described by JazzyNico, this is rather tedious to reproduce with local builds on OS X (tested with lp:inkscape/0.92.x, GTK+/X11 2.24.29 and GTK+/Quartz 2.24.30), and happens rarely in regular usage.

I have not been able to reproduce it with Inkscape 0.91 at all - it might be possible that this behavior originates in or was exposed by changes from the merge of the fill-n-stroke-cppify (r14160) - I recall that after the merge I started to notice occasionally a defunct fifth slider displayed in some of the color modes (not persistent).

su_v (suv-lp)
summary: - HSL tab in 0.92pre2(beta)
+ HSL tab in 0.92 corrupted: colors in hue slider incorrect, defunct 5th
+ slider at the bottom
Revision history for this message
Frank Rysanek (frr) wrote :

Thanks for the swift response gentlemen :-)

@jazzynico: I've been using 0.91 64b since shortly after its release (and 0.48.something 32b on XP for many months/years? before that) and I don't recall seeing this "HSL bug".

At a closer look, I can keep working with 0.92. I can see the actual hue live on the object being modified, and the bug doesn't seem to crash the running Inkscape session... Thanks for the great job that you're doing :-)

Revision history for this message
Hachmann (marenhachmann) wrote :

For what it's worth, I've also never seen this in 0.91.

Revision history for this message
Brynn (brynn4inks-deactivatedaccount) wrote :

No I never saw in 0.91 (32 bit, exe installer/64-bit 7z) and it's almost always showing for me in 0.92 (64 bit, exe installer)(and 0.92pre3 64-bit 7z)). (Windows 7 Home and Pro, 64-bit)

Yes, I share Frank's experience that the hue slider functions properly. It's just the visual display that's wrong. The incorrect display makes it hard to use, but it does function properly (applies the correct color) if you use the slider or spin the numbers.

jazzynico (jazzynico)
tags: added: regression
jazzynico (jazzynico)
Changed in inkscape:
milestone: none → 0.93
Revision history for this message
Brynn (brynn4inks-deactivatedaccount) wrote :

Just to mention this specifically, so it won't get missed.

On the Stroke paint tab of Fill and Stroke dialog, on the HSL tab, the label for each bar is missing. See screenshot which compares the HSL tab on Fill and Stroke paint tabs.

H:, S:, L:, and A:

to the left of their respective element, are missing.

Thanks :-)

Revision history for this message
Duarte Ramos (duarte-framos) wrote :

Sorry for the late response, I though I subscribed this but apparently commenting does not subscribe automatically.

Anyway just to confirm that this never showed up in any 0.91 builds I ever used since release, but it is relatively easy to trigger in any 0.92 builds.

After further testing I managed to find a reliable way to trigger the bug in 0.92.1 under Windows 7 64bits:

- Create two objects, one with a gradient fill one with a solid fill.
- Make sure you have the HSL tab as current
- Switch to the gradient editor tool
- Pick the object with gradient fill
- Edit one gradient stop by clicking on it in the canvas
- Immediately after, still with the Gradient Editor tool active and the gradient stop selected for editing, click in an object with the solid fill
- Ghost slider should appear in HSL tab
- Clicking back in the gradient stop should make it go back

There seems to some slight change over original 0.92 builds, the problem seems to not 'stick around' as much. Also in 0.92 one could trigger the bug with a single object by editing the gradient stop while simultaneously changing to solid fill, whereas in 0.92.1 that no longer seems possible.

Revision history for this message
Alexey (allkhor) wrote :

Reproduced on Xubuntu 16.04 x86_64 with 0.92.1 and 0.92.0+devel+15614+85.
Possible simple trigger:
1) Create a two shapes and fill a different colors(or the same colors).
2) Open Object->Objects... dialog.
3) Switch between objects in a objects dialog(or multiple click on a one).

Revision history for this message
shark0r (shark0r) wrote :

I found the cause: ColorScales::_mode is not initialized in the constructor.

The constructor calls ColorScales::setMode(), and there is a line "if( _mode == mode) return;" in that function which _mode is ColorScales' member and mode is a parameter of the constructor. This assumes _mode's initial value is 0 so setMode() may not actually execute.

Why this problem only occurs in HSL tab? In theory _mode's initial value is undefined and this problem happens a bit randomly. In my environment _mode will frequently be the following values.

when building RGB tab (mode=1) -> _mode=3
HSL tab (mode=2) -> _mode=2 (cause setMode() doesn't actually run)
CMYK tab (mode=3) -> _mode=1

Patch attached, although only 1 line is changed.

Revision history for this message
jazzynico (jazzynico) wrote :

Thanks for your investigations and for the patch!
Tests in progress.

Changed in inkscape:
assignee: nobody → shark0r (shark0r)
status: Triaged → In Progress
Revision history for this message
jazzynico (jazzynico) wrote :

Patch tested successfully on Xubuntu 16.04, lp:inkscape, and committed rev. 15627.
Thanks!

Changed in inkscape:
status: In Progress → Fix Committed
Revision history for this message
jazzynico (jazzynico) wrote :

Proposing to backport to 0.92.2.

tags: added: backport-proposed
Revision history for this message
Brynn (brynn4inks-deactivatedaccount) wrote :

Great job!

Thanks :-)

Revision history for this message
Patrick Storz (ede123) wrote :
Patrick Storz (ede123)
tags: removed: backport-proposed
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.