GTK2 / GTK3 - Display problems with Scrapbook X

[mseliger]

I've a problem with the GTK3-versions of Palemoon / Basilisk-browser. When I use the Scrapbook X extension then the capturing dialog is different to the one with GTK2.

The arrow on the dropdown-box of the title is missing (or not shown) with GTK3 (but it works - there is a little free space, where you can click).

In Palemoon, GTK 2:

Palemoon GTK2

In Palemoon and Basilisk, GTK3:

Basilisk GTK3 / Palemoon GTK3

Does someone know a solution?

[Moonchild]

Does someone know a solution?

The scrapbook X dev needs to either account for GTK3 widgets or include their own graphic for the widget.

[Nuck-TH]

The scrapbook X dev needs to either account for GTK3 widgets or include their own graphic for the widget.

It is editable <menulist>. No additional CSS rules set for this element. How else to account?

[Lootyhoof]

This actually could be a platform issue. It looks like the dropmarker for menulist[editable="true"] isn't being given any width in GTK 3 for some reason. SeaMonkey seemed to work around this in bug #1331208 with a small CSS hack - we could probably apply this cleanly to menulist.css if we want the same approach.

[New Tobin Paradigm]

Looks like a solution to me but I would suggest using MOZ_WIDGET_GTK == 3 as the conditional because GTK2 doesn't require it and we still target GTK2 buildablity. This, also, does not mean Moonchild was incorrect as an extension developer CAN account for this somewhat on the edge of an edge case but it SHOULD be promoted to a platform issue.

Either way, If we want this in the Minor/Security release scheduled for next Tuesday it will have to be fixed today. Someone, open an issue.

[jobbautista9]

Even without the conditional it seems to work fine in GTK2, so I don't think the conditional is needed.

I will be opening an issue and a PR applying the min-width fix.

This is what it looks like in GTK3 with the min-width fix:

Compare to GTK2 (which has the min-width fix applied):

EDIT: Opened Issue #1774 (UXP) and Issue #1775 (UXP)

[mseliger]

Thank you all for your support .

[New Tobin Paradigm]

Damn it, did EITHER of you test every GTK2 theme engine and every theme on every distro to make sure it won't be a problem? I know Moonchild didn't.

I don't give explicit instructions just so they can be arbitrarily ignored. Adding the preprocessor conditional (and a comment) as I suggested was the SAFE option to ensure it wouldn't introduce issues. I also wanted to test my self under a few conditions before merging after my nap. Which is why I said open an issue NOT pr and instamerge.

EVEN IF YOU ARE CORRECT AND NOTHING SCREWED UP WILL HAPPEN.. it still should have been better tested. Guess the rule is never take a nap because people will do whatever while you aren't watching every second of every day.

[Moonchild]

Did you want it fixed today OR NOT?!

[New Tobin Paradigm]

Oh yeah, cause that's logic. No, not if the fix is going to have any possibility of causing issues with GTK2 styling.

All we know at this moment is it MIGHT NOT based on one screenshot of one theme on one control in one extension on one application on one distro that isn't even cited merged without any other testing by you who dismissed the issue in the first place.

[Moonchild]

You know what?
I'll back it out and it can wait just stop your complaining.

And do me a favour. Next time don't rush people then blow up because people don't test every possible contingency because you rushed them. If you want everything tested extensively on every distro then don't tell them to fix something RIGHT NOW. because that's asking the impossible. We still aren't using quantum development.

[New Tobin Paradigm]

I didn't even demand anyone do anything other than open an issue and I merely stated that it needs to be in today if it is going to be in the release next week. Today does not mean instantly. Just an hour of testing would have been needed but if you are gonna put this on me then don't continue your days-long pissy behavior when I get a little upset at being cut out of the equation and ignored for no reason.

[Moonchild]

Sure. I won't continue my "pissy behaviour".

did EITHER of you test every GTK2 theme engine and every theme on every distro to make sure it won't be a problem? I know Moonchild didn't.

You can do that in an hour? Good man if so. i don't believe it.

Or, you know, you could have just filed a follow-up that adds the #ifdef instead of getting upset and blaming everyone but yourself.

[New Tobin Paradigm]

I would build a GTK3 build then flip through a fuck ton of themes. It isn't that difficult but NOT having the conditional was not in the anticipated plan but if that was to be a thing it would need more extensive testing at least two builds and flipping through lots more themes.

When you ignore conditional states and don't include them you widen the scope of what COULD go wrong. THAT IS MY POINT HERE. That and being bypassed for no reason. also. there would be no reason to follow up and just, you know, add the ifdef if it hadn't been instamerged.

Now since you obviously think I am wrong.. Do explain WHAT and HOW what I said isn't the PROPER thing to do or are you just approaching it from the familiar standpoint of being mad at me because you think this is merely about me being upset with you making a decision I didn't approve of because I think I need to control everything cause if it is.. It ain't and I am sick of everyone assuming that shit.

But know what? I'm not going to do that. I'll take a page from your book and give up and just let whatever happens happen. Why don't we just get our barely existent linux developer to handle it instead cause obviously neither one of us is doing it right.

The ONLY decision I made incorrectly today was waking up from my nap. I should have just slept through till tomorrow.

[Moonchild]

I never said you were wrong code-wise. You are absolutely right.

[New Tobin Paradigm]

So if I am not wrong codewise and I KNOW I am not wrong testing wise.. Then WHY was it merged? Cause THAT is the point of contention.

[Moonchild]

WHY was it merged? Cause THAT is the point of contention.

Because it was tested, just not as extensive as you'd like because of time restrictions.

If we want this in the Minor/Security release scheduled for next Tuesday it will have to be fixed today. Someone, open an issue.

http://developer.palemoon.org/docs/release-engineering/

Tuesday - Firefox Release Day
The master branches will be placed under a "CLOSED TREE" type of condition where no high-risk patches and feature merges will be permitted until after merge day.

Mind you, Tuesday is in 3 hours for me.

If you'd rather I not merge PRs anymore on the platform, just let me know. I certainly can do without all this unnecessary animosity.

[New Tobin Paradigm]

Oh ffs. Just don't be so quick to instamerge PRs without testing being done. Also, with conditional to GTK3 only it isn't a big risk. As just GTK-anything it COULD have unintended consequences even if it might not. ALSO Tuesday is 9 hours away for me. That is why we generally stick to UTC but we also know that Firefox won't be released until -sometime- tomorrow and security patches will be days away. It is just good not to merge risky patches during that week and you know that.

[Moonchild]

I'm not gonna argue. Testing was done. The PR could be better. Everyone of us made mistakes here, be it in completeness or haste or clarity or demands or emotional response.
Want to make sure it lands? Then stop being here and redo the PR and get it tested and merged while I'm unconscious. G'night.

[New Tobin Paradigm]

It is in progress and I hope you do get some quality sleep.