Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I built a drupal gardens site on an ipad but found that I couldn't scroll the overlay. This was using 'Perfect Browser' not Safari. It seems reasonable that we get core to work on iPhone/iPad versions of Safari.
Comment | File | Size | Author |
---|---|---|---|
#15 | 878020-15-fix-overlay-use-absolute.patch | 896 bytes | Mark Trapp |
#12 | 878020-12-fix-overlay-mobile-safari.patch | 901 bytes | Mark Trapp |
#8 | 878020-8-fix-overlay-mobile-safari.patch | 1.02 KB | Mark Trapp |
#9 | 878020-9-fix-overlay-mobile-safari.patch | 964 bytes | Mark Trapp |
Comments
Comment #1
casey CreditAttribution: casey commentedI read somewhere you need to use two-finger-drag to scroll iframes (which overlay is) on iphone/ipad. Does that work?
Comment #2
Jody LynnNo, that doesn't work and I confirmed the same problem in Safari on iPad.
Comment #4
scottrouse CreditAttribution: scottrouse commentedI'm having the same trouble, as well. I understand this probably isn't critical, but it does seem fairly major.
The two-finger technique does not work in this situation.
Comment #5
scottrouse CreditAttribution: scottrouse commentedChanged tags...
Comment #6
ksenzeeI would be interested to know if the patch at #841184-38: "Skip to main content" link doesn't work correctly in the overlay fixes the scrolling problem.
Comment #7
Mark Trapp#841184-38: "Skip to main content" link doesn't work correctly in the overlay does not solve the problem in Mobile Safari.
Why wouldn't this be critical? It renders the system unusable for a whole platform when using the Standard install profile.
Comment #8
Mark TrappInterestingly, the fix is similar to the fix for IE6: Mobile Safari hates
position: fixed
, but is fine withposition: absolute
. Basically,position: fixed
elements are attached to the page body, but when you "scroll" in Mobile Safari, you're moving the viewport, not the page body. Thus,position: fixed
elements never move or resize.Unfortunately, there are no CSS hacks that let you target just Mobile Safari, so here's a stab at a patch that uses jQuery to check for iPad, iPhone, or iPod. It checks for a Mobile Safari platform in
Drupal.overlay.eventhandlerOuterResize
at the same place it checks for IE6, then sets the position to absolute rather than fixed.Comment #9
Mark TrappIt would help if I followed coding standards before submitting a patch. Here's a rerolled patch of #8:
Comment #10
Mark TrappI really want to set this as critical, but I'd like to hear from someone else as to why it wouldn't be. iOS accounts for 59% of the mobile web market, and without a fix, this renders a standard Drupal 7 install unusable. Seems like it'd be crazy to do another release, beta, or otherwise, with the standard Drupal 7 installation not working on iOS.
Comment #11
ksenzeeIn my opinion this is not even a major bug. Drupal's list of targeted browsers doesn't include Mobile Safari, and anyone using iOS can either disable javascript or use another browser to set their user preferences not to use overlay. It's way less important than making overlay accessible for screenreader users, who can't just switch to another browser.
I don't have an iOS device, so I can't test the patch. But is there any reason we need to make this change inside an event handler that gets called every time someone resizes the window? Wouldn't once during attach() be sufficient?
Comment #12
Mark TrappIt should be done after the overlay is created, but it does not need to be done on resize. I've moved the code to Drupal.overlay.open; attached is a new patch.
I understand what you're trying to say, but Safari is a supported browser, and it's a very odd thing to say that to get a site functioning in a supported browser, you need to use a different browser first to disable a shipping portion of Drupal. That Drupal 7 is unusable for an entire platform is pretty silly: it'd be like not supporting Mac users and telling them "well, in theory, you should have access to a Windows computer, so use that."
It's not like we're talking about an API change or a massive overhaul; it's a minor style change that's scoped for the specific platforms that need it.
Comment #13
moshe weitzman CreditAttribution: moshe weitzman commentedWell, lets just fix the bug.
Comment #14
casey CreditAttribution: casey commentedCan't we just use position:absolute for all?
Comment #15
Mark TrappIf there's a reason why we can't use
position:absolute
wholesale, I can't see it. Getting rid of the check in #12 and replacingposition:fixed
withposition:absolute
seems to work fine in:IE 6 was using
position:absolute
already, so that's covered.Perhaps someone with deeper knowledge of the overlay can explain why it was
position:fixed
, but attached is a patch for review that changes it toposition:absolute
for everything, solving the problem. It also gets rid of the CSS hacks we were using for IE6 so it could useposition:absolute
.Comment #16
casey CreditAttribution: casey commentedWell I should have but I really don't remember :p
Comment #17
Mark TrappComment #18
Mark TrappIn the interest of pushing this issue forward, I spent some time testing the proposed patch in #15—changing
position:fixed
toposition:absolute
—in every browser targeted by Drupal.My testing methodology was to apply the patch, enable Overlay, and navigate to every top-level page in the toolbar (e.g. Content, Structure, Configuration). On each page, I confirmed the Overlay loaded correctly, the links were accessible, and that the Overlay scrolled. I ignored issues that occurred with or without the patch.
My results are below (TL,DR: everything passes). I checked to make sure the patch in #15 still applies, and it does. Is there anything else that needs to be tested to get this RTBC and committed?
Firefox
Opera
* Note: In all Opera versions, using the mouse wheel to scroll causes the Overlay frame to scroll with background once the bottom of the page is reached. Using scrollbars works correctly.
Internet Explorer
Safari
Comment #19
moshe weitzman CreditAttribution: moshe weitzman commentedBased on those awesome tests and casey's suggestion for absolute, i'd say this is rtbc.
Comment #20
sunUm. position:fixed is completely valid CSS. If a modern browser does not support it, then that's a straight browser bug.
Lots of other CSS in Drupal core and contrib uses position:fixed. There's absolutely no point in changing that.
I can barely accept that we still bend Drupal 7 to some extent to "at least work" in IE6, but everyone knows the special situation.
There is no such special situation with modern browsers. File a bug report against that browser instead.
Not changing any issue properties, but this issue is a straight won't fix for me.
Comment #21
moshe weitzman CreditAttribution: moshe weitzman commentedWhy choose sides? We should give a great experience to these users AND file a browser bug.
Comment #22
Mark TrappThere is no bug to be filed: it's a different interaction model.
With a desktop browser, there's a window that can be resized with a viewport that's attached to the window. When you resize the window, all the fixed elements are placed according to the dimensions of the window because the viewport remains static. It's to that window that
position:fixed
elements are attached.In iOS, Android, and most other modern mobile devices, there is no resizable window, and the viewport acts independently of the window. When the page is first loaded,
position:fixed
elements rightfully attach themselves to the window. But when the user interacts with the page by panning or zooming, the window remains the same: what's actually moving is the viewport.Since the window hasn't changed, the
position:fixed
elements remain in place (rightfully), but to the user, they present a problem because they are getting in the way of what the user sees in the viewport. iOS/Android/mobile browsers are following the CSS spec to the letter, but because they provide a different experience, the spec does something counterproductive.More information about the issue:
And there is no apparent reason why the Overlay needs fixed positioning: the only reason to use fixed positioning, a subset of absolute positioning, is to ensure elements remain fixed to a static viewport. The Overlay doesn't need to do that: it merely needs to be outside the page flow.
Switching to absolute is a one line change, works in every browser, gets rid of the IE6 special-casing in overlay-parent.css, and allows the interaction model in a new, very large class of browsers to work.
Comment #23
casey CreditAttribution: casey commentedI think position:fixed is a leftover from when we actually positioned the overlay in the center of the parent portview. Now overlay's iframe covers the whole window and there is just no reason to stick with position:fixed no more. Just get this in.
Comment #24
Damien Tournoud CreditAttribution: Damien Tournoud commented@Mark Trapp: please stop spreading marketing crap here. The way mobile webkit handles
position: fixed
is clearly against the spec. They did this because those elements are *very* costly to render, and do not fit in the "render in a buffer and just scroll that" method that those browsers use.From CSS 2.1:
And "viewport" is defined as:
The "viewport" is not the whole canvas, it's the area of the canvas that the user currently sees. Nothing in mobile touch platforms changes that. Rendering
position: fixed
the same wayposition: absolute
is rendered is just a violation of the spec. With very good reasons, but a violation nonetheless.Comment #25
Mark Trapp@casey Thanks for the reasoning; that makes sense.
@Damien Tournoud There's no need to be hostile; it's really counterproductive. We are both trying to make Drupal better, not worse.
I can't find anything that supports this. Can you provide a link?
Nothing did change that. The "viewport" in Mobile Safari/Mobile Chrome isn't the whole canvas, and it is what the user currently sees.
I agree. But that's not what Mobile Safari/Mobile Chrome does. If it were, either this wouldn't be an issue and the Overlay would scroll fine unchanged, or the Overlay would break in desktop browsers when the positioning was changed to absolute. Neither occurs.
I feel like I haven't explained the issue properly, and I apologize for that confusion. The change between desktop browsers and browsers like Mobile Safari is pretty subtle. Perhaps Apple's own explanation of the difference can help explain it better:
Comment #26
Damien Tournoud CreditAttribution: Damien Tournoud commentedAnd this is exactly the part the marketing BS I'm talking about. It's not yours, and I'm not attacking you personnally.
The viewport *is* the viewable content area. Making a "viewport" vs. "viewable content area" distinction just doesn't make any sense.
Comment #27
oriol_e9gAll browsers have some (small/big) spec violations, I think that this shouldn't be all the debate.
What is the advantage of using position: fixed? more correct code?
Comment #28
Damien Tournoud CreditAttribution: Damien Tournoud commentedJust to clarify: this issue is RTBC; I have no problem with that.
Comment #29
Mark Trapp@Damien Tournoud there isn't a distinction being made between the viewport and the viewable content area. If you go back to the spec for fixed positioning, there are three conditions for satisfying the spec:
Mobile Safari/Chrome satisfy (1): fixed positioning is a subcategory of absolute positioning. They satisfy (2): the containing block is established by the viewport. When you first load a page, fixed elements are presented correctly as the viewport is in the same place as the window. And they satisfy (3): fixed boxes do not move when the document is scrolled.
I think the confusion arises in your interpretation of (2) and (3). With browsers that have resizable windows, the behavior of fixed elements you've come to expect— fixed elements appear to remain fixed to the viewport—because they are established by the viewport, which is rebuilt when the window is resized or scrolled. (3) doesn't make sense in this context, because the viewport is constantly being rebuilt, which means its constantly reestablishing the containing block.
In Mobile Safari/Chrome, the viewport isn't being rebuilt, because the window can't change. There is no event that triggers a viewport rebuild other than a refresh of the page. So, as to the spec, the viewport does establish the containing block which contains the fixed elements. But when the viewport is moved, (3) now comes into play: the fixed boxes must not move when the document is scrolled.
And this is what occurs: when you move the viewport in Mobile Safari/Chrome, fixed elements do not move; they remain in the position they were in when the viewport first established the containing block.
Interpreting w3c specs is tricky, and we can go back and forth over it all day. But this issue comes down to 5 things:
There doesn't seem to be a technical reason to block this change. If there is, we should talk about that and get it addressed.
Comment #30
Mark Trapp@Damien Tournoud ah, crosspost. Great. I appreciate the concerns you've raised.
@oriol_e9g casey in #23 mentioned that the Overlay used to be fixed within the center of the screen, for which fixed positioning would be useful. As it is now, either is correct (for most values of correct), as fixed positioning inherits all the properties of absolute positioning plus two more (how the containing block is established, fixed elements do not move). Those two are not necessary for the Overlay to function, and affect certain browsers, so I'd say for the rest of the values of correct, absolute is...more correct.
Comment #31
Damien Tournoud CreditAttribution: Damien Tournoud commentedThe viewport is what the user sees. Fixed elements are positioned according to the viewport. As a consequence, fixed elements should remain visible when you scroll the viewport. The fact that the window and the view port can or cannot be resized has nothing to do with it, and there is not a lot of room for interpretation here: Mobile Webkit is in violation of the spec.
It doesn't *really* matter, because they did this for very good reasons (rendering fixed elements is responsible for most of the complexity of the refresh engine - and Webkit trunk has been broken twice this year by attempts to improve the way the refresh algorithm handles fixed elements), but it is a violation nonetheless.
Comment #32
Dries CreditAttribution: Dries commentedDecided to commit this. Thanks.