position:fixed prevents iOS devices from scrolling the Overlay

I read somewhere you need to use two-finger-drag to scroll iframes (which overlay is) on iphone/ipad. Does that work?

I'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.

Changed tags...

I 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.

#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.

Interestingly, the fix is similar to the fix for IE6: Mobile Safari hates position: fixed, but is fine with position: 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.

It would help if I followed coding standards before submitting a patch. Here's a rerolled patch of #8:

I 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.

In 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?

It 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.

Well, lets just fix the bug.

Can't we just use position:absolute for all?

If 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 replacing position:fixed with position:absolute seems to work fine in:

• Safari 5 (including Mobile Safari)
• Chrome 6
• Firefox 3.5, 3.6, and 4
• Internet Explorer 7 and 8

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 to position:absolute for everything, solving the problem. It also gets rid of the CSS hacks we were using for IE6 so it could use position:absolute.

Well I should have but I really don't remember :p

In the interest of pushing this issue forward, I spent some time testing the proposed patch in #15—changing position:fixed to position: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

• Firefox 3.6.12: Pass
• Firefox 3.5.15: Pass
• Firefox 3.0.12: Pass
• Firefox 2.0.0.20: Pass
• Firefox 1.5.0.7: Pass

Opera

• Opera 10.63: Pass*
• Opera 10.54: Pass*
• Opera 10.10: Pass*
• Opera 10.01: Pass*
• Opera 9.64: Pass*
• Opera 9.52: Pass*
• Opera 9.27: Pass*

* 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

• Internet Explorer 8: Pass
• Internet Explorer 7: Pass
• Internet Explorer 6: Pass

Safari

• Safari 5.0.2: Pass
• Safari 4.0.5: Pass
• Safari 3.2.1: Pass
• Safari 3.1.2: Pass
• Safari 2.0.4: Overlay is not enabled for this browser

• Safari for iOS 4.2: Pass
• Safari for iOS 4.1: Pass
• Safari for iOS 4.0: Pass
• Safari for iPhone OS 3.2: Pass
• Safari for iPhone OS 3.1: Pass
• Safari for iPhone OS 3.0: Pass

Based on those awesome tests and casey's suggestion for absolute, i'd say this is rtbc.

Um. 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.

Why choose sides? We should give a great experience to these users AND file a browser bug.

There 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:

• Regarding Fixed Positioning in Mobile Safari by Cameron Daigle
• Fixed positioning in Mobile Safari by Richard Herrera

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.

I 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.

@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:

fixed: The box's position is calculated according to the 'absolute' model, but in addition, the box is fixed with respect to some reference. As with the 'absolute' model, the box's margins do not collapse with any other margins. In the case of handheld, projection, screen, tty, and tv media types, the box is fixed with respect to the viewport and does not move when scrolled.

And "viewport" is defined as:

User agents for continuous media generally offer users a viewport (a window or other viewing area on the screen) through which users consult a document. User agents may change the document's layout when the viewport is resized (see the initial containing block).

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 way position: absolute is rendered is just a violation of the spec. With very good reasons, but a violation nonetheless.

@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.

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.

I can't find anything that supports this. Can you provide a link?

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.

Nothing did change that. The "viewport" in Mobile Safari/Mobile Chrome isn't the whole canvas, and it is what the user currently sees.

Rendering position: fixed the same way position: absolute is rendered is just a violation of the spec.

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:

CSS fixed positioning works in Safari on iPhone and iPad, but not as you might expect. While elements that use fixed positioning in Safari on Mac OS X and Windows always stay on screen, elements that use fixed positioning in Safari on iPhone and iPad can end up offscreen as users zoom and pan the webpage. Why does this happen?

By definition, the containing block of a webpage element that uses CSS fixed positioning is the viewport. This means that when you set position: fixed with a bottom and right value of 20px as shown in Listing 1-4, you have "fixed" the position of an element 20 pixels above the bottom edge of the viewport, and 20 pixels from the right edge of the viewport.

Listing 1-4. CSS fixed positioning.

#fixed {
   position: fixed;
   right: 20px;
   bottom: 20px;
   height: 100px;
   width: 100px;
   background-color: purple;
}

In Safari on the desktop, the viewport is analogous to the window — as you resize a window, you are resizing the viewport. As you scroll, you are scrolling the viewport. Hence, in Safari on Mac OS X and Windows, the element always stays on screen.

Safari on iPad and Safari on iPhone do not have resizable windows. In Safari on iPhone and iPad, the window size is set to the size of the screen (minus Safari user interface controls), and cannot be changed by the user. To move around a webpage, the user changes the zoom level and position of the viewport as they double tap or pinch to zoom in or out, or by touching and dragging to pan the page. As a user changes the zoom level and position of the viewport they are doing so within a viewable content area of fixed size (that is, the window). This means that webpage elements that have their position "fixed" to the viewport can end up outside the viewable content area, offscreen.

In Safari on the desktop, the viewport is analogous to the window — as you resize a window, you are resizing the viewport. As you scroll, you are scrolling the viewport. Hence, in Safari on Mac OS X and Windows, the element always stays on screen.

Safari on iPad and Safari on iPhone do not have resizable windows. In Safari on iPhone and iPad, the window size is set to the size of the screen (minus Safari user interface controls), and cannot be changed by the user. To move around a webpage, the user changes the zoom level and position of the viewport as they double tap or pinch to zoom in or out, or by touching and dragging to pan the page. As a user changes the zoom level and position of the viewport they are doing so within a viewable content area of fixed size (that is, the window). This means that webpage elements that have their position "fixed" to the viewport can end up outside the viewable content area, offscreen.

And 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.

All 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?

Just to clarify: this issue is RTBC; I have no problem with that.

@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:

1. Fixed positioning is a subcategory of absolute positioning.
2. The only difference is that for a fixed positioned box, the containing block is established by the viewport.
3. For continuous media, fixed boxes do not move when the document is scrolled.

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:

1. The Overlay is unusable for a significant set of browsers
2. Getting the Overlay usable for these browsers requires a one line CSS change
3. The current CSS is not necessary for the Overlay to function
4. The change works in all targeted browsers and complies with the CSS spec
5. A patch is ready to go

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.

@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.

The 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.

Decided to commit this. Thanks.