Closed Bug 1376756 Opened 3 years ago Closed 2 years ago

Twisty not visible on selected treerow with Linux High Contrast theme

Categories

(Core :: Widget: Gtk, defect)

54 Branch
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: aarnaud, Assigned: samuel.thibault)

References

Details

Attachments

(6 files, 4 obsolete files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170627100221

Steps to reproduce:

1) Choose the High Contrast theme on your GNU/Linux distribution. Here on Debian 8.8 gnome-themes-standard "3.14.2.2"
2) Sort mails by thread
3) Place the keyboard on a threaded mail (so with a right arrow)



Actual results:

The right arrow is invisible since I've switched from Thunderbird 45 to Thunderbird 54.0b3. The issue also appears on Thunderbird 52.2.1.


Expected results:

The right arrow should be visible
We use the arrow, the Mozilla toolkit provides to us. Please can you check how Firefox shows this arrow in the left pane of the Library (open all bookmarks)?
Flags: needinfo?(alexarnaud)
(In reply to Richard Marti (:Paenglab) from comment #2)
> We use the arrow, the Mozilla toolkit provides to us. Please can you check
> how Firefox shows this arrow in the left pane of the Library (open all
> bookmarks)?

It's totally correct. I can reproduce the same issue on Firefox Nightly.

So what should I do ? Do I should close this bug and open another one to the core component ?

Thanks for your help.

Best regards.
Flags: needinfo?(alexarnaud)
Thank you Alex. I move the bug to Core.
Component: Untriaged → Widget: Gtk
Product: Thunderbird → Core
Summary: right arrow no longer visible when High Contrast is selected → Twisty not visible on selected treerow with Linux High Contrast theme
Dear all,

I've recompile Thunderbird 52 with GTK2 on Debian 8 "Jessie" and the problem disappears.

Best regards.
Hello all,

It's an issue related to the GTK3 migration. On Debian 8 "Jessie", the current HighContrast theme seems not ready for GTK3 and it looks like it's not an issue related directly to Firefox/Thunderbird but theming so I believe we could close this issue.

Best regards.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
Attached image bookmarks.png
Hello,

I have dived more into the issue.

The gtk3 HighContrast theme is now ready for GTK3, and we still have the issue, see the attached screenshot: the twisty of the selected line is hardly visible.

What happens is that in moz_gtk_treeview_expander_paint, we don't know which row of the treeview is selected, and thus GTK_STATE_FLAG_SELECTED is not set for selected rows, and thus the light version of the twisty is not used as the theme expects to be for selected rows. From the comment there, 

    /* Because the frame we get is of the entire treeview, we can't get the precise
     * event state of one expander, thus rendering hover and active feedback useless. */

I assume it would be hard to get to know which row is selected?

For our own uses, we will for now just modify the color of the twisty to be a mid-gray which is visible both on white and black backgrounds.  Ideally we'd however only do this for firefox & thunderbird since in other applications gtk properly selects the dark or gray variant. I have however not found examples to do so in gtk, or even just documentation in gtk about the possibility. Do you know if that is possible, through e.g. a css selector? The gtk inspector was not so helpful since for that part it shows only one big item for the whole panel...

Samuel
(by "big item", I mean a MozContainer widget just inside the GtkWindow, without any style class, and nothing inside that)
Alex, I guess this should be marked back as OPEN since missing to pass GTK_STATE_FLAG_SELECTED really is on the mozilla side?
Attached image twisty.png
Oops, sorry, I misinterpreted "not visible" in the title. Alex meant that it was not showing up at all, while what I am talking about is the twisty not being visible enough when it is selected. I have attached a screen shot: on the selected line, according to the high contrast theme the twisty is supposed to be rendered with a lighter color to make it visible with the black background. But firefox does not provide the information that the line is selected, and thus the dark twisty icon is used, hardly visible on the black background.
I've change the state from resolved invalid to unconfirmed because the expander is not contrasted, even on GTK3.

Best regards,
Alex.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
FTR, I tried to add

treeview.view.expander {
        color: #0f0;
}

to my userChrome.css, and it didn't affect the bookmarks twisties, while putting

* {
        color: #0f0;
}

affects my whole browser, except twisties.

On the other hand, putting

treeview.view.expander {
        color: #0f0;
}

in my gtk.css, twisties get affected, in all my applications and firefox as well.
Attached image inspector.png
I tried to use the browser inspector, but it does not get into the bookmarks elements, it only sees <treechildren class="sidebar-placesTreechildren">.

I tried to use 

treechildren {
	color: #0f0;
}
.sidebar-placesTreechildren {
	color: #0f0;
}

with no effect. I guess treechildren is just a container and the rendering is done another way.
More precisely, putting 

treechildren {
	color: #0f0;
}
.sidebar-placesTreechildren {
	color: #0f0;
}

in userChrome.css does have effect: it makes the text of the bookmars green. But the twisties remain unchanged.
while putting it in gtk.css does not get any effect at all.
Richard, can you please take a look.
Flags: needinfo?(richard.marti)
Setting colors in CSS for the twisties doesn't work on Mozilla level as it uses with -moz-appearance: treetwisty; the GTK icon.  To set the color we'd need  SVG icons. But then we have only one shape and it wouldn't follow the Linux theme shape.
Flags: needinfo?(richard.marti)
Ok, so using userChrome.css won't work with some code work. But is there a selector that could be used in gtk.css to match only firefox twisties?

(and of course I'm only talking about a workaround here, the real question is “ I assume it would be hard to get to know [in moz_gtk_treeview_expander_paint] which row is selected? ”)
(In reply to Samuel Thibault from comment #18)
> Ok, so using userChrome.css won't work with some code work.

I meant without* some code work.
> I assume it would be hard to get to know [in moz_gtk_treeview_expander_paint] which row is selected?

AIUI, it would mean adding to DrawWidgetBackground some flags parameter to pass the state of the widget in addition to the existing aWidgetType, and use that in GetGtkWidgetAndState to put GTK_STATE_FLAG_SELECTED  into aWidgetFlags.

I can work on this approach, I just need confirmation, before taking the time to do it, that there is agreement over it?
(we could even just pass a reference to the whole mScratchArray to DrawWidgetBackground)
Just making sure to get attention :)

Richard, perhaps you can comment on my proposal in comment 20+21? (or redirect to somebody else who would know about the code I am talking about?)
Flags: needinfo?(richard.marti)
I'm sorry, I can't help here as I'm only working on theme's CSS. Maybe Karl Tomlinson could help.
Flags: needinfo?(richard.marti)
(In reply to Samuel Thibault from comment #22)
> Just making sure to get attention :)
> 
> Richard, perhaps you can comment on my proposal in comment 20+21? (or
> redirect to somebody else who would know about the code I am talking about?)

I move the NI on Karl Tomlinson as said in the previous comment.

Best regards,
Alex.
Flags: needinfo?(karlt)
There does seem to be a mismatch between the DrawWidgetBackground() parameters
and nsTreeBodyFrame, because a single nsTreeBodyFrame maps to many objects,
potentially having different states.

Perhaps the parameters are not good for their purpose.  Perhaps a
ComputedStyle* parameter would be more fit for purpose than nsIFrame*, but I
suspect ComputedStyle may not be sufficient for all widgets.

I'm not so keen on adding a flags parameter to DrawWidgetBackground().

If this problem is generic to many frame types, then all the different kinds
of flags are likely to get overloaded and hard to track.  Perhaps a
ComputedStyle parameter could replace the aWidgetType parameter, but I don't
know whether this would suit all callers, if they don't cache the entire
ComputedStyle.  Passing a mozilla::AtomArray could be very generic, but its a
fairly heavyweight structure.  Another thing to think about would be whether
the approach extends to GetWidgetBorder() and other methods.

However, I suspect that nsTreeBodyFrame is special in representing many
objects with different states.  If so, then I'd prefer a solution specific to
nsTreeBodyFrame.

nsTreeBodyFrame is already storing local state in mScratchArray on the frame
during calls to DrawWidgetBackground, and so I suggest QueryFrame to
nsTreeBodyFrame in GetGtkWidgetAndState() and either fetch the array (by
adding nsTreeBodyFrame::GetPropertyArrayForCurrentDrawingItem(), for example)
or query the desired state from the frame.  Calling back into the frame for
state of the current item is a bit weird, but OK for a particular situation,
and it does seem to follow the design of nsTreeBodyFrame.

An alternative could be to add NS_THEME_TREETWISTY_SELECTED and
NS_THEME_TREETWISTY_OPEN_SELECTED.  That doesn't scale well for multiple
orthogonal properties, but is reasonably simple if the number of states
doesn't get out of control.

ni? in case Markus has any thoughts or preferences?
Flags: needinfo?(karlt) → needinfo?(mstange)
Attached patch patch (obsolete) — Splinter Review
It does work quite nicely by providing the atoms array indeed, see the attached patch. We do have potential for quite a few orthogonal properties indeed. While at it, I have added the hover property which indeed helps for accessibility.
Attached patch twisties (obsolete) — Splinter Review
Oops, that was a work version. Here is a proper version, following the suggestions, and containing the GTK2 part.
Attachment #8986463 - Attachment is obsolete: true
(In reply to Samuel Thibault from comment #28)
> It is being tried on
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=d8dff63bfcce05c281ec9b44940876ffafc783f2

I'm testing a build provided by Samuel and I can confirm that it solves this issue from the user point of view.

Best regards,
Alex.
Comment on attachment 8986481 [details] [diff] [review]
twisties

Perhaps karlt could already review this?
Attachment #8986481 - Flags: review?(karlt)
Attached patch twisties (obsolete) — Splinter Review
Here is a revised patch: the previous version wasn't effecting the open twisties, which have a different NS_THEME_ constant.
Attachment #8986481 - Attachment is obsolete: true
Attachment #8986481 - Flags: review?(karlt)
Attachment #8987355 - Flags: review?(karlt)
Comment on attachment 8987355 [details] [diff] [review]
twisties

layout/xul/tree belongs to Core::XUL, which is unowned according to
https://wiki.mozilla.org/Modules/Core so I guess I can review even those files.

   ImgDrawResult PaintBackgroundLayer(ComputedStyle*      aComputedStyle,
                                      nsPresContext*       aPresContext,
                                      gfxContext&          aRenderingContext,
                                      const nsRect&        aRect,
                                      const nsRect&        aDirtyRect);
 
 
+public:
+  // This returns the property array where widget ports can store atoms for
+  // style during draw. E.g. nsTreeBodyFrame's gtk port stores whether the row
+  // currently being drawn is selected, hovered, etc.
+  mozilla::AtomArray* GetPropertyArrayForCurrentDrawingItem() { return &mScratchArray; }
+
+protected:
   // An internal hit test.  aX and aY are expected to be in twips in the
   // coordinate system of this frame.
   int32_t GetRowAt(nscoord aX, nscoord aY);

Please insert the new method at the end of the existing public methods,
instead of among protected methods.

It is not the widget ports that *store* atoms for style, but nsTreeBodyFrame.
and nsTreeBodyFrame stores the same atoms regardless of platform.
The GTK widget port will *use* this information for native drawing.
Please adjust the comment in line with this.

Code should be wrapped to stay within 80 columns (even though this file is not
consistent about that).
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Classes
demonstrates the modern format for methods in class definitions that need more
than one line.

+      mozilla::AtomArray *atoms = treeBodyFrame->GetPropertyArrayForCurrentDrawingItem();

Please wrap at '=' to stay within 80 columns.

Please include more context in future patches:
That can be done by including this in ~/.hgrc or .hg/hgrc:
[diff]
git = true
showfunc = 1
unified = 8
Attachment #8987355 - Flags: review?(karlt) → review+
Flags: needinfo?(mstange)
Attached patch twisties (obsolete) — Splinter Review
Here is the revised patch, which can be checked in.
Attachment #8987355 - Attachment is obsolete: true
It seems I can't add the checkin-needed keyword myself, and Alex tells me he can't either. Karl, I guess you can?
Flags: needinfo?(karlt)
We need a try run before this can be pushed.
This one has the wrong author on the changeset (because the patch comes from a foreign tool), but is good enough to test the changes.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=268d9fe19efbe97e87f21624cd11b5732194a26a
Flags: needinfo?(karlt)
Comment on attachment 8987469 [details] [diff] [review]
twisties

>+  mozilla::AtomArray* GetPropertyArrayForCurrentDrawingItem() { return &mScratchArray; }

The body needs to be reformatted because this won't fit on a single line.

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Classes
demonstrates the modern format for methods in class definitions that need more
than one line.
Well, there was already a try on

 https://treeherder.mozilla.org/#/jobs?repo=try&revision=d8dff63bfcce05c281ec9b44940876ffafc783f2

but better be safe than sorry.
Mmm, there is indeed a failure that needs investigation:

Crash reason:  SIGSEGV
Crash address: 0xe8

 0  libxul.so!bool nsTArray_Impl<RefPtr<nsAtom>, nsTArrayInfallibleAllocator>::Contains<nsStaticAtom*>(nsStaticAtom* const&) const [nsTArray.h:268d9fe19efbe97e87f21624cd11b5732194a26a : 509 + 0x0]
 1  libxul.so!nsNativeThemeGTK::GetGtkWidgetAndState(unsigned char, nsIFrame*, WidgetNodeType&, GtkWidgetState*, int*) [nsNativeThemeGTK.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 312 + 0x19]
 2  libxul.so!nsNativeThemeGTK::DrawWidgetBackground(gfxContext*, nsIFrame*, unsigned char, nsRect const&, nsRect const&) [nsNativeThemeGTK.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 1107 + 0x37]
 3  libxul.so!nsDisplayThemedBackground::PaintInternal(nsDisplayListBuilder*, gfxContext*, nsRect const&, nsRect*) [nsDisplayList.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 4501 + 0x31]
 4  libxul.so!mozilla::FrameLayerBuilder::PaintItems(nsTArray<mozilla::AssignedDisplayItem>&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, gfxContext*, nsDisplayListBuilder*, nsPresContext*, mozilla::gfx::IntPointTyped<mozilla::gfx::UnknownUnits> const&, float, float) [FrameLayerBuilder.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 6425 + 0x16]
 5  libxul.so!mozilla::FrameLayerBuilder::DrawPaintedLayer(mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::DrawRegionClip, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, void*) [FrameLayerBuilder.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 6584 + 0x18]
 6  libxul.so!mozilla::layers::ClientPaintedLayer::PaintThebes(nsTArray<mozilla::layers::ReadbackProcessor::Update>*) [ClientPaintedLayer.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 164 + 0x24]
 7  libxul.so!mozilla::layers::ClientPaintedLayer::RenderLayerWithReadback(mozilla::layers::ReadbackProcessor*) [ClientPaintedLayer.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 314 + 0xb]
 8  libxul.so!mozilla::layers::ClientContainerLayer::RenderLayer() [ClientContainerLayer.h:268d9fe19efbe97e87f21624cd11b5732194a26a : 58 + 0xd]
 9  libxul.so!mozilla::layers::ClientLayerManager::EndTransactionInternal(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::DrawRegionClip, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) [ClientLayerManager.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 375 + 0xa]
10  libxul.so!mozilla::layers::ClientLayerManager::EndTransaction(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::DrawRegionClip, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) [ClientLayerManager.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 433 + 0x11]
11  libxul.so!nsDisplayList::PaintRoot(nsDisplayListBuilder*, gfxContext*, unsigned int) [nsDisplayList.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 2762 + 0x17]
12  libxul.so!nsLayoutUtils::PaintFrame(gfxContext*, nsIFrame*, nsRegion const&, unsigned int, nsDisplayListBuilderMode, nsLayoutUtils::PaintFrameFlags) [nsLayoutUtils.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 3837 + 0x5]
13  libxul.so!mozilla::PresShell::Paint(nsView*, nsRegion const&, unsigned int) [PresShell.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 6315 + 0x17]
14  libxul.so!nsViewManager::ProcessPendingUpdatesPaint(nsIWidget*) [nsViewManager.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 480 + 0x28]
15  libxul.so!nsViewManager::ProcessPendingUpdatesForView(nsView*, bool) [nsViewManager.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 412 + 0xd]
16  libxul.so!nsViewManager::ProcessPendingUpdates() [nsViewManager.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 1102 + 0x11]
17  libxul.so!nsRefreshDriver::Tick(long, mozilla::TimeStamp) [nsRefreshDriver.cpp:268d9fe19efbe97e87f21624cd11b5732194a26a : 2039 + 0x8]
...


Could it be that something else than a nsTreeBodyFrame would be passed to DrawWidgetBackground with NS_THEME_TREETWISTY or NS_THEME_TREETWISTYOPEN, through the css treetwisty keyword for instance, that would make its way to the mAppearance member used in nsDisplayThemedBackground::PaintInternal?
Comment on attachment 8987469 [details] [diff] [review]
twisties

>+  mozilla::AtomArray* GetPropertyArrayForCurrentDrawingItem() { return &mScratchArray; }

I think it would be helpful to make this return const, so that it is clear
that the array is not modified outside this class.

It could even be const mozilla::AtomArray& for consistency with
GetComputedStyle(), which would clarify that this is never null.

https://searchfox.org/mozilla-central/rev/14cb8f1c238735ba1abe18ad44e39808983c2572/layout/xul/tree/nsTreeStyleCache.cpp#40

>+    } else if (aWidgetType == NS_THEME_TREETWISTY ||
>+               aWidgetType == NS_THEME_TREETWISTYOPEN) {
>+      nsTreeBodyFrame *treeBodyFrame = do_QueryFrame(aFrame);
>+      mozilla::AtomArray *atoms =
>+        treeBodyFrame->GetPropertyArrayForCurrentDrawingItem();

NS_THEME_TREETWISTY(OPEN) comes from CSS, which could be applied to frames
that are not nsTreeBodyFrames.

The result of do_QueryFrame needs to be null-checked to be certain this is an
nsTreeBodyFrame.  I expect that will fix the crash.
Attached patch twistiesSplinter Review
I have run the attached revised patch through the run server:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=976878648e359cef3eec5794d666337295c7147b

There seems to be only a couple of unrelated timeouts.
Attachment #8987469 - Attachment is obsolete: true
Attachment #8988140 - Flags: review?(karlt)
Comment on attachment 8988140 [details] [diff] [review]
twisties

Thank you for making those changes.
Attachment #8988140 - Flags: review?(karlt) → review+
https://hg.mozilla.org/try/raw-rev/0cba7a84ebd4 is the same patch in hg format with author.
Keywords: checkin-needed
Assignee: nobody → samuel.thibault
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(In reply to Karl Tomlinson (:karlt) from comment #42)
> https://hg.mozilla.org/try/raw-rev/0cba7a84ebd4 is the same patch in hg
> format with author.
Which can be imported with |hg qimport https://hg.mozilla.org/try/raw-rev/0cba7a84ebd4|.
(In reply to Jorg K (GMT+2) from comment #43)
> (In reply to Karl Tomlinson (:karlt) from comment #42)
> > https://hg.mozilla.org/try/raw-rev/0cba7a84ebd4 is the same patch in hg
> > format with author.
> Which can be imported with |hg qimport
> https://hg.mozilla.org/try/raw-rev/0cba7a84ebd4|.

Do you think we could backport the fix for Thunderbird 60? Should we need to open a new bug for that?

Best regards,
Alex.
I was waiting for this question ;-) - No new bug required, I already have a list of Gecko bugs (bug 1423895, bug 1429125 (bug 1439323), bug 1456988) that will get special backport to TB 60 ESR. I'll take note.
Pushed by csabou@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b36d448ce918
gtk: while drawing nsTreeBodyFrame, fetch current row attributes for proper style rendering. r=karlt
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/b36d448ce918
Status: ASSIGNED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
(In reply to Karl Tomlinson (:karlt) from comment #25)
> However, I suspect that nsTreeBodyFrame is special in representing many
> objects with different states.  If so, then I'd prefer a solution specific to
> nsTreeBodyFrame.

I agree, and I think you've arrived at a good solution.
FWIW, we're not using -moz-appearance: treetwisty anymore.
Alex, the patch is part of this build:
https://treeherder.mozilla.org/#/jobs?repo=comm-esr60&revision=92075e129ec53a38060f3d4431216e011031be8f

Please download a binary by clicking onto one of the B's and try it.
Flags: needinfo?(alexarnaud)
It works fine as well in thunderbird indeed, thanks!
Status: RESOLVED → VERIFIED
(In reply to Jorg K (GMT+2) from comment #51)
> Alex, the patch is part of this build:
> https://treeherder.mozilla.org/#/jobs?repo=comm-
> esr60&revision=92075e129ec53a38060f3d4431216e011031be8f
> 
> Please download a binary by clicking onto one of the B's and try it.

Hello Jorg and sorry for the delay, I was in holidays,

I'm visual-impaired, I don't see or understand where to download the build you've mentioned, could you be more precised? I've never done it before.

Best regards,
Alex.
Flags: needinfo?(alexarnaud) → needinfo?(jorgk)
You can get TB 60 ESR build 3 (RC1) from here:
https://archive.mozilla.org/pub/thunderbird/candidates/60.0-candidates/build3/

No more clicking on B's ;-)
Flags: needinfo?(jorgk)
(In reply to Jorg K (GMT+2) from comment #54)
> You can get TB 60 ESR build 3 (RC1) from here:
> https://archive.mozilla.org/pub/thunderbird/candidates/60.0-candidates/
> build3/
> 
> No more clicking on B's ;-)

I've finally tested the build. It was an issue of treeherder not compatible with Firefox ESR 52 that makes me crazy. The fix works correctly. I've tested it on Debian unstable (Sid).

Thanks a lot for the quick fix in TB :).

Best regards,
Alex.
See Also: → 1494595
You need to log in before you can comment on or make changes to this bug.