Last modified: 2013-04-22 16:15:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T46635, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 44635 - Search box attachment off edge of page in Monobook
Search box attachment off edge of page in Monobook
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
GuidedTour (Other open bugs)
master
All All
: High normal (vote)
: ---
Assigned To: Matthew Flaschen
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-04 09:29 UTC by Matthew Flaschen
Modified: 2013-04-22 16:15 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Matthew Flaschen 2013-02-04 09:29:37 UTC
In Monobook, the step attached to the search box goes off the edge of the page, since it's on the left side of the screen.  https://en.wikipedia.org/wiki/Main_Page?tour=test&step=3&useskin=monobook .  This step is attached to #searchInput with position bottomRight.

It would be nice if we at least ensured that the absolutely positioned guiders didn't go off the screen.  This could be done by setting top and left to a minimum of 0.
Comment 1 Matthew Flaschen 2013-02-04 09:41:32 UTC
It might also be possible for the library to override the angle chosen (e.g. bottomRight) and use something else (e.g. right in this case) if it detects that the original would go off the screen.
Comment 2 Steven Walling 2013-02-04 23:29:32 UTC
Overriding the angle isn't a bad idea. It would be elegant to have it flip orientation. In the meantime, feel free to also just change the parsed item to a more neutrally-positioned one, for a short term fix for production.
Comment 3 Matthew Flaschen 2013-02-08 22:00:46 UTC
Rather than trying to automatically compensate (which could be wonky), what if we allow tours to specify behavior in multiple skins?

Tours could keep using the current syntax that just expresses a single string, like:

attachTo: '#searchInput',
position: 'bottomRight',

So it's no more work at first writing a tour.

But for multiple skin support, also allow:

attachTo: '#searchInput',
position: {
  default: 'bottomRight',
  monobook: 'right'
}

We could also support:

attachTo: {
  default: '#searchInput',
  monobook: '#somethingElse'
},
position: {
  default: 'bottomRight',
  monobook: 'right'
}

In some cases, skins have different selectors for the same or equivalent thing.  So it seems to make sense to implement both, working the same way.

It would first check for an override, but then fall back to to default (so you can customize for anywhere from none to all of the skins).
Comment 4 Matthew Flaschen 2013-02-08 22:33:01 UTC
This is very similar to how ResourceLoader skinScripts and skinStyles work, including the 'default' fallback key.
Comment 5 Terry Chay 2013-02-08 22:34:45 UTC
I like this idea, but how do add support for this in a manner that can be upstreamed to Guiders?
Comment 6 Matthew Flaschen 2013-02-08 22:39:17 UTC
There is already a wrapper method for initGuider (initializeGuiderInternal), which is used for internationalization, and making the button code at more high-level.

This particular one probably is not a candidate for upstraming (neither is the MW i18n-specific stuff).  

However, the fix I'm about to do for bug 44804 (automatic flipping for RTL) is a candidate if they're interested.  I'll probably do it in the wrapper for now, but I'll send upstream a note in case they think it would be useful there.
Comment 7 Matthew Flaschen 2013-02-12 07:25:55 UTC
Do you think I should do something like:

position: {
  skin: {
    default: 'bottomRight',
    monobook: 'right'
  }
}

to try to be more future-proof, in case there's something else we need to fork on?

Or, keep it simple?
Comment 8 Terry Chay 2013-02-12 22:22:47 UTC
I think it's probably best to keep it simple (don't have a "skin") section, and avoid upstreaming it a la i18n changes. I know it's a small difference, but let's not make it more confusing.

If we do it this way and the user doesn't have a default but goes to the old style (where it's a string instead of an object) this will be handled fine right?
Comment 9 Matthew Flaschen 2013-02-12 22:28:21 UTC
Yeah, I'm not going to upstream this part either way, since it doesn't make sense for other stuff.

Yes, it will handle the simple/old syntax.

Alright, I'll go with the simple approach.  Ideally, there should be no other reason to distinguish (e.g. RTL flipping is now handled).
Comment 10 Matthew Flaschen 2013-02-13 06:39:39 UTC
Fixed in https://gerrit.wikimedia.org/r/#/c/48790/ as originally proposed (simpler version without skin: key).
Comment 11 Matthew Flaschen 2013-02-14 20:56:06 UTC
At Ori's suggestion, I changed default to fallback, so people don't have worry about reserved words.

This is now merged.
Comment 12 Matthew Flaschen 2013-03-08 21:57:32 UTC
We decided to do the automatic flipping as well.  See https://bugzilla.wikimedia.org/show_bug.cgi?id=45621 .

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links