Closed Bug 1026641 Opened 6 years ago Closed 6 years ago

Styling of 'Done' button on IRCCloud messed up on :focus

Categories

(Core :: Layout, defect, P2)

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla33

People

(Reporter: sawrubh, Assigned: mats)

References

(Depends on 1 open bug, )

Details

(Keywords: regression)

Attachments

(5 files, 2 obsolete files)

Steps to reproduce:
* Open IRCCloud, join any channel, click on any user, select Whois
* A dialog opens up with some text and a button on the top right.

What happens:
The button appears empty, without any text or styling. When you click anywhere else on the dialog (basically lose focus from the button) the button becomes normal. Works fine on stable Chrome and stable Firefox.

What should happen:
The button should be rendered properly on focus.
Saurabh, can you try to find a regression window for this using mozregression?
Flags: needinfo?(saurabhanandiit)
Product: Firefox → Core
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a6a457fe2a2a&tochange=80431d4fd0da is the regression window when it bisects the nightlies, when it tries to bisect inbound I get this error (and some output which might help) : https://pastebin.mozilla.org/5441538
Flags: needinfo?(saurabhanandiit)
(In reply to Saurabh Anand [:sawrubh] from comment #2)
> https://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=a6a457fe2a2a&tochange=80431d4fd0da is the regression
> window when it bisects the nightlies, when it tries to bisect inbound I get
> this error (and some output which might help) :
> https://pastebin.mozilla.org/5441538

Thanks! The error is a mozregression bug, no worries - the m-c range here is helpful enough.

Mats, bug 427928 is in the regression range, and because the loss of focus from the button fixes it (see comment #0), I suspect that may be the cause here. Does that seem at all plausible to you?
Flags: needinfo?(mats)
The rendering is what the author specified:

https://d33go1xh9ghg2t.cloudfront.net/build/main-cfeee032.css
line 87:
button:focus a,button:focus span{outline:auto 4px #1E72FF;outline-offset:-2px}
Flags: needinfo?(mats)
As the author, I'm not sure how that styling specifies what was reported as "The button appears empty, without any text or styling"
Attached image Screenshot
The button isn't empty for me so I didn't notice that, sorry.
This screenshot is what Linux64 Nightly renders for me.
sawrubh, are you using a non-default desktop theme?  which version of the gtk
libraries do you have on your system?
Flags: needinfo?(saurabhanandiit)
Attached image QlpowKl.png
This is how it looks on my system. I'm on Gnome 3.10.4 and have no Themes applied in Firefox if that's what you meant.
Flags: needinfo?(saurabhanandiit)
Attached file about:support output
about:support output from my Nightly.
Does disabling "Ubuntu Firefox Modifications" (and restarting Firefox)
make a difference?

> have no Themes applied in Firefox if that's what you meant.

No, I meant desktop theme in Ubuntu.
I tried disabling "Ubuntu Firefox Modifications" but it doesn't help. I don't know what themes are in Gnome DE in Ubuntu. I checked the tweak tool and have set everything to default but still the bug is happening.
OK, thanks for your help.
Assignee: nobody → mats
Component: General → Layout
Priority: -- → P2
Blocks: 427928
fwiw, I have hardware acceleration and xrender disabled and this bug still happens.
It seems best to just disable this whole thing until we can figure
out which [Gnome] environments works and which don't, and that may
take a while.
Attachment #8445361 - Flags: review?(roc)
Comment on attachment 8445361 [details] [diff] [review]
(wdiff) Put outline:auto rendering behind a pref and disable it by default

>+// Is layout of CSS outline:auto enabled?
>+pref("layout.css.outline-auto.enabled", false);

Shouldn't this refer to outline-style: auto since the auto value is part of the outline-style longhand property?

Also, if we stop supporting the value, should we stop parsing it?  Or does does "disabled" mean treated as 'solid' (which the spec allows)?  (If so, should the pref say that?)
(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #16)
> Shouldn't this refer to outline-style: auto since the auto value is part of
> the outline-style longhand property?

That would be more precise, yes.

> Also, if we stop supporting the value, should we stop parsing it?  Or does
> does "disabled" mean treated as 'solid' (which the spec allows)?  (If so,
> should the pref say that?)

My intent is to return to the state before bug 427928 (to minimize
risk) which is to parse the value but not render any outline.
Judging by the age of bug 427928 that has been the state for many
years.

Not parsing it, or rendering it as solid, both seems risky to me
(in terms of web compat) for little gain.  It seems better to
go back to a known state for a little while until we sort out
this issue and then re-enable it.
s/outline-auto/outline-style-auto/  etc, as dbaron suggested
Attachment #8445361 - Attachment is obsolete: true
Attachment #8445362 - Attachment is obsolete: true
Attachment #8445361 - Flags: review?(roc)
Attachment #8445405 - Flags: review?(roc)
Attached patch fixSplinter Review
Comment on attachment 8445405 [details] [diff] [review]
(wdiff) Put outline:auto rendering behind a pref and disable it by default

Review of attachment 8445405 [details] [diff] [review]:
-----------------------------------------------------------------

OK, but maybe we should turn it on for Windows and Mac?
Attachment #8445405 - Flags: review?(roc) → review+
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #20)
> OK, but maybe we should turn it on for Windows and Mac?

That seems like it would be a hassle for authors to deal with since
the layout would be different, in the sense of visible outline /
no outline, on different platforms.  And later when this issue
is resolved there will be a change again.

I think it's better to wait until it's ready to be enabled
by default.
https://hg.mozilla.org/mozilla-central/rev/c4cce8a31e2c
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
(Filed bug 1031664 on re-enabling it again eventually.)
Depends on: 1034018
QA Whiteboard: [good first verify]
Depends on: 1215596
You need to log in before you can comment on or make changes to this bug.