User Details
- User Since
- Oct 19 2015, 9:36 PM (173 w, 5 d)
- Availability
- Available
- IRC Nick
- jan_drewniak
- LDAP User
- Jdrewniak
- MediaWiki User
- Unknown
Thu, Feb 14
One question raised during estimation was how much we want to change the existing HTML to accommodate the new design. It is probably possible to achieve the "equidistant" design (equally spaced menu items) without changes to the markup, but the effort involved in that in probably substantial. Currently one item is floated right, with the new design we might have to use display:table and maintain an entirely separate stylesheet for this that overrides the current layout.
Tue, Feb 12
@Niedzielski It might be an issue with the storybook implementation, that specific preview looks fine in production...
We discussed in grooming today that having a promisedView component would have some significant benefits and make this work easier, so we should create a task to document that work and consider that a dependency for this task.
Following up from yesterdays discussion, one thing we talked about is when it's appropriate to use and event bus and when it's not.
@Edtadros yup that's a feature.
a LOT of things have changed since I last looked at the editing codebase, for the better!
- The editing code has been migrated to webpack T213340!
- The error parsing logic is now separated into a parseSaveError.js file, no longer mixed in EditorOverlay.js, hurra!
- Unit tests have been improved.
- Deferred .fails have been replaced with .rejects.
- The bugs with conflict errors have been resolved
@greg there are a few problems that I know of that could prevent it from working:
- The patch has multiple tasks associated with it (i.e. Bug: T1234, T12345 in the commit message)- currently the link will only show up for the first task (this can be fixed).
- The board has hundreds of tasks - Gerrit limits the query length to 50 terms, so work board with more than 50 tasks won't work :/ I could potentially split the queries into multiple chunks though.
Mon, Feb 11
@alexhollender I'm not sure what changed but I'm unable to see the bug with the blue read-more text being clickable, either on staging or locally on master, so I'm handing this over to QA :)
Fri, Feb 8
It'd be good to put this on staging to double check, but I think the simple fix works.
Thu, Feb 7
as far as I can tell, setting this line to z-index:0; (or @z-indexBase) seems to fix the issue...
It looks like the scope of this task has expanded from "Wikitext editor error handling broken for edit-conflicts" to "everything wrong with edit error-handling on mobile". I'll see if I can track down the work already done in this area and break this up into smaller tasks.
Wed, Feb 6
@alexhollender I've updated readers-web-staging with the following patches, there was an error checking the Minvera patch out the last time. The spacing below the title should be ok now.
Tue, Feb 5
Mon, Feb 4
thanks for spotting that @Edtadros!
Fri, Jan 25
@phuedx yes! meant to do that..
alrighty, and for part two of this two pointer, the text width.
@alexhollender part one of this two part two-pointer, the headings.
Thu, Jan 24
I don't think the minHideDelay is used for animation. I think that's a hack to get around attaching the window.click event in the onShowDrawer method. In a previous patch (which I just slowly walked away from... ) I attempted to add another timer for the hide method. It's kind of brittle because I hard-coded the duration at 250ms, which is a value that's actually changed in CSS.
Thanks for the bug report. We currently don't officially support the Recent Changes page on mobile, but we have an project Advanced Mobile Contributions to do so this year, so we'll fix this when we expose the Recent Changes page on mobile, tracked in T178194.
Wed, Jan 23
I really think we should also be updating Drawer.prototype.onHideDrawer to also remove the class has-drawer it adds in postRender. Patch to follow.
Tue, Jan 22
Oh, when I saw an anchor tag with href="#movedpara_3_10_rhs" I assumed there was an element with that same ID on the page. Nope.
So it seems to work when I put the scroll-behavior: smooth; rule on the <html> element instead of the <body>... kinda.
It only starts scrolling after the second tap. I have no idea why that is. I haven't found anything intercepting the click events (yet?).
Fri, Jan 18
This error also occurs on desktop:
https://zh.wikipedia.org/w/index.php?diff=52813452
Jan 17 2019
Jan 16 2019
After looking through the code, I think the regression might have been caused by use moving modules around during the refactor, and causing some CSS files to be loaded in a different order.
This task has proven difficult as I’ve learned more about how Overlays and Drawers work, and how they interact with OverlayManager.