User Details
- User Since
- Nov 18 2014, 11:57 PM (190 w, 5 d)
- Availability
- Available
- IRC Nick
- mooeypoo
- LDAP User
- Mooeypoo
- MediaWiki User
- Mooeypoo [ Global Accounts ]
Fri, Jul 13
I found the culprit and fixed it; the WindowManager has z-index set for 101; I set the popup overlay to be 110. It works for me now.
I think by default, actions appear on top and bottom, so while that is considered OOUI dialog's "normal" behavior (to have buttons on footer/top, if the design is different here, then we shouldn't bother.
An ActionWidget would just be a [widget][button] set, like input/button or input/label, etc.
Thu, Jul 12
@Mooeypoo your patch gives me this:
because the .mw-widget-dateInputWidget-calendar has a z-index of 1 I guess... I'm trying to track down why it's getting the bottom scroll bar (it shouldn't ever, should it?).
Okay, here's my general thoughts on this, but I think we should delve a little deeper and make some decisions about what we consider a good default behavior for these things.
Wed, Jul 11
I'm changing this to unbreak now, since we can't merge anything into PageTriage. It consistently fails, due to #3. Please help on this.
Tue, Jul 10
@MMiller_WMF this is on testwiki, ready for your review.
@MMiller_WMF This is in test wiki, testable.
@MMiller_WMF this is ready to test; let me know if my reproduction explanation is lacking -- the title language is a little confusing.
Another failure; same as #3, but happened today as well: https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-hhvm-docker/6989/consoleFull
Fri, Jul 6
Yep. If you look at the Echo popup and try to open a sub menu (dotdotdot) at the lower end, you'll see it opens downwards but isn't confined by the general popup.
I would definitely not lose it completely; I'm thinking of keyboard accessibility, and losing focus is not really helpful.
Yeah, those aren't buttons, though, those are OptionWidgets.... They're not quite the UX of a "click to do an action" but more of a "I select this content to see" so the behavior is different, but we might be able to get something similar with volker's assistance.
That's ooui's focus feature for accessibility. I'd highly recommend against removing it... :/
I'm confused; is the text input focused or the button? If it's the button, you just clicked it, it looks like the correct behavior? What should happen instead?
That's actually pretty complicated. We have a couple of tasks about similar issue with pop-ups that we need to fix in ooui. It has to do with changing the logic of popup widget and clippable and its a bit of a mess.
Thu, Jul 5
This is probably coming from the animation. Without your patch, there is an "opening" animation going on when the "Are you sure..." is appearing. In order to make it work, it has to start with width:0 and end with its natural width. When the string is not wrapping, the span "just" grows into the full line -- but when we make the string wrap, the changing width actually changes how much the text wraps -- which changes the height too.
Tue, Jul 3
Followup from discussion in teh gerrit commit, putting my full analysis here for posterity:
Mon, Jul 2
@Volker_E The way we currently have those messages with OO.ui.Alert() is that they pop a secondary window on top of the existing window. I agree this looks weird, and I'd love us to fix it, but we should do that in OOUI itself, not in this product.
@Hagarshilo this is pretty interesting... one idea that you could explore is to have your fix only work for diff pages. Look for a class (probably on <body>) that is on diff pages specifically, and add that class as a super selector to your rule.
IT's not a perfect solution, since the original bug may happen in history pages too, but it seems to have less chances of existing there anyways (?)
Sun, Jul 1
Sat, Jun 30
Fri, Jun 29
Hmm. This is odd, but it seems to be the same problem as T198445: Markers not appearing. I can't reproduce this exact effect to test if that patch fixes it, but just from generally knowing what caused the previous patch (mismatching selectors) I anticipated this one may be fixed as well.
Thu, Jun 28
We could add a "read more" link under (or at the end) of the template description that sends people to the template page, and with that, get rid of the need to show long descriptions anyways?
This probably isn't the best solution ever, sicne it will override previous values -- but it only happens if the user unclicked both checkboxes anyways, and it will only potentially override the specific unreviewed/reviewed checkbox state, so I think that's acceptable for a quickfix.
Wed, Jun 27
Tue, Jun 26
Mon, Jun 25
Hmm. This is a question we should discuss and solve in general, but there are multiple reasons why widgets (it's not just TagMultiselectWidget, it's also Combo*Widget, MenuSelectWidget, and the entire inner operations of 'findItemByData()' in OOUI) look for items by their data rather than label.
Thu, Jun 21
Wed, Jun 20
While we fix this specifically for RCFilters, I think this shows a discrepancy we have in OOUI as well.
Tue, Jun 19
Mon, Jun 18
Jun 13 2018
I am going to raise a slightly philosophical point, so bear with me, and let's discuss a bit.
@Pginer-WMF I went by your designs, but I had a problem creating the separator line between the "show/hide" button and the query name; I could only get it to be 100% height (from top to bottom) and I can't manage to get it to be a smaller one.
Jun 12 2018
Jun 11 2018
This was merged into OOUI, so it should be available in the next release. I'm tagging it as "Blocked" but we should re-test when OOUI is released again.
@Volker_E, I don't remember, when is the next release due? I think in about 2 weeks?
Jun 10 2018
Jun 8 2018
The above commit should fix this behavior inside OOUI itself. Thanks for spotting it!
Jun 6 2018
Sorry, I completely botched the gerrit process by making a new commit rather than overriding the old one.
(Also, I just noticed I didn't change the commit title -- I just did in the actual gerrit patch, but the posting for gerritbot is the wrong one)
This is the same type of bug we had before with touchstart/mousedown/click on iOS safari.
There was very weird consensus on the previous (unresloved) patch that seemed to say that 'click' is best but iOS seems to have issues with occasionally not emitting it correctly.
We can't use 'touchstart', though, because that's also emitted on scroll. The patch comments were a little confusing, so I thought my amended commit is worth -- can we recheck if this is resolving the issue?
Jun 5 2018
Whoops, thanks for finding this! Patch incoming.
Found the culprit rule.