Last modified: 2014-09-17 19:20:43 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 T56965, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 54965 - OOjs UI: ClippableElement shouldn't assume the body height is 100%
OOjs UI: ClippableElement shouldn't assume the body height is 100%
Status: RESOLVED FIXED
Product: OOjs UI
Classification: Unclassified
General (Other open bugs)
unspecified
All All
: High major
: ---
Assigned To: Ed Sanders
:
: 68370 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-04 10:22 UTC by Elitre
Modified: 2014-09-17 19:20 UTC (History)
6 users (show)

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


Attachments

Description Elitre 2013-10-04 10:22:13 UTC
user report:
<<In Monobook, when I first open the dialogue and type a character into the "add template" text field, the field will get grey stripes for a second, and then the suggestions drop down menu will appear for a split second but then disappear again (too quick to use). Pressing backspace and trying again doesn't do anything, clicking away and clicking back and trying again doesn't do anything. Closing the dialogue and reopening it will cause the behaviour to repeat, however, but of course to no use. Behaviour is normal with Vector skin. FF 24 Win7. --Atethnekos (Discussion, Contributions) 07:40, 4 October 2013 (UTC)>>
Same for me.
Comment 1 Elitre 2013-10-28 11:48:18 UTC
Just reporting this is still happening.
Comment 2 Elitre 2013-12-02 15:57:33 UTC
Also, the same happens when you try to add a category.
Comment 3 Alex Monk 2014-02-27 23:59:28 UTC
Seems to be to do with OO.ui.ClippableElement.prototype.clip using this.$clippableContainer (the <body> of the dialog frame), which if you inspect in developer tools appears to cover no area in monobook but covers the full dialog frame in vector. .innerHeight() returns 0 on monobook so desiredHeight is calculated as a negative number (Which jQuery inserts as 0px).

I think this is because Vector sets height: 100% on body elements, but Monobook doesn't.
Comment 4 Gerrit Notification Bot 2014-03-06 18:32:27 UTC
Change 117241 had a related patch set uploaded by Alex Monk:
Set body height to 100% in monobook

https://gerrit.wikimedia.org/r/117241
Comment 5 Bartosz Dziewoński 2014-03-07 00:01:29 UTC
Alex's diagnosis looks correct. The <html> and <body> elements on the inner frame do actually have a height of 0px, because all of their children are (in this particular example, this might not always be the case) absolutely positioned. 

Setting their height to 100% in CSS makes <html> span the entire height of its docment (the iframe one in this case) and <body> the entire height of the <html>, solving the issue.

Normally the styles set in the outer document do not apply to documents in <iframe>s, but the OO.ui.Frame.static.transplantStyles method copies them when the frame is created.


Since OOjs UI definitely shouldn't depend on `html, body { height: 100% }` being present in page's CSS, I see two solutions to this (someone more knowledgeable about the structure of OOjs should decide which one is saner, or some up with a better one):

* Make OO.ui.Frame.static.transplantStyles set <html>'s and <body>'s height
  to 100%. This would be trivial to do but feel hacky to me.

* Use this.$clippableWindow instead of this.$clippableContainer in
  OO.ui.ClippableElement.prototype.clip when measuring heights, or just pass
  the window as the container to the constructor in these particular cases.
  This may or may not be a good idea.
Comment 6 Gerrit Notification Bot 2014-03-07 00:10:51 UTC
Change 117241 abandoned by Alex Monk:
Set body height to 100% in monobook

Reason:
That was basically what I was expecting, thanks Bartosz

https://gerrit.wikimedia.org/r/117241
Comment 7 Bartosz Dziewoński 2014-09-17 18:46:32 UTC
Ed has independently applied my second suggestion from March in 8bd708b9d5260defef664346523a6d78c14c4837 two months ago, as a fix for bug 68370 (which is a duplicate of this one), so this looks properly fixed to me.
Comment 8 Ed Sanders 2014-09-17 19:17:04 UTC

*** This bug has been marked as a duplicate of bug 68370 ***
Comment 9 James Forrester 2014-09-17 19:20:43 UTC
*** Bug 68370 has been marked as a duplicate of this bug. ***

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


Navigation
Links