White Space Pull-Down Issue on iOS Web Pages: Cause Analysis and Solutions

When developing web applications on iOS devices, many developers encounter a common interaction issue: when pressing and dragging the screen up or down with a finger, an extra white blank area appears at the edge of the screen. Although this issue seems trivial, it seriously undermines the integrity of the page and the user experience, especially standing out obtrusively in applications with a unified design style. This article will deeply analyze the generation mechanism of this problem and provide two practical and feasible solutions.

I. Problem Manifestation: Intuitively Visible Interaction Abnormalities

The manifestation of this problem is very clear, mainly reflected in two scenarios: first, when pressing and dragging the screen down with a finger, the top of the screen will detach from the page content, exposing a white area inconsistent with the main style of the page, and the page will bounce back to the normal position after releasing the finger; second, when pressing and dragging the screen up with a finger, a similar white blank area will appear at the bottom of the screen, which also returns to normal after releasing the finger. The appearance of this blank area has nothing to do with the page content, and this phenomenon may occur even if the page content is sufficient or less than one screen.

II. Root Cause: Triggering of iOS WebView's Default Behavior

To solve this problem, it is first necessary to understand the technical principles behind it. In iOS's Safari browser or applications based on WebView, the touch and drag operation of a finger on the screen will trigger a series of touch events, and the core of the problem lies in the default behavior of the touchmove event.

Mobile touch events mainly include three core types: touchstart (the finger starts to touch the DOM element), touchmove (the finger drags on the DOM element), and touchend (the finger moves away from the DOM element). When the user drags the screen up and down, the triggered touchmove event acts on the entire WebView container, and the default processing logic of the iOS system for this event is to allow dragging the WebView itself. When the WebView is dragged beyond the scope of the page content, the area not covered by the content will appear as a white blank, which is the essence of the problem.

III. Solutions: From Event Control to Function Transformation

In response to the above causes, we can start from two different perspectives and select appropriate solutions in combination with actual business scenarios.

Solution 1: Monitor Touch Events to Precisely Control Sliding Behavior

The core idea of this solution is to monitor the touchmove event and use the preventDefault() method to prevent the default dragging behavior of the WebView, while ensuring that elements inside the page that need to be scrolled (such as scroll lists) are not affected.

1. Core Principle: Block Default Behavior with preventDefault()

According to the definition of touch events in the W3C document: "If the preventDefault() method is called on the first touchmove event of an active touch point, it should prevent all default behaviors caused by touchmove events related to that active touch point, such as scrolling." This means that we can use this method to precisely block the overall dragging of the WebView, while "giving the green light" to elements that need to be scrolled.

2. Implementation Steps: Filter Scroll Containers to Avoid Over-Blocking

If all touchmove events are directly prevented, scrollable elements inside the page (such as <div style="overflow: scroll;">) will also lose their scrolling function. Therefore, the key is to "distinguish scenarios" - only prevent dragging that acts on the entire WebView, and allow scrolling inside elements.

The specific implementation is divided into two steps:

1. Add an identifier to the scroll container: add a custom attribute or class name to elements in the page that need to be scrolled (such as scroll lists) to identify the identifier when the touch event is triggered. For example, mark the scroll element as a scrollable container by adding a custom attribute _isScroller: true to it.
2. Monitor the touchmove event and make judgments: monitor the touchmove event on document.body, and when the event is triggered, judge whether the target element is a scroll container. If yes, allow it to pass; if not, call preventDefault() to prevent the default behavior.

3. Code Implementation

// 1. Add identifier to scroll container (take Vue as an example, similar for other frameworks or native)
// DOM structure of scroll element: <div ref="scrollContainer" class="scroll-container">...</div>
mounted() {
  // Add custom attribute to scroll container to mark it as scrollable element
  this.$refs.scrollContainer._isScroller = true;
}

// 2. Listen to touchmove event and control default behavior
document.body.addEventListener('touchmove', function(e) {
  // Traverse parent elements of the event target to check for scroll container identifier
  let target = e.target;
  while (target) {
    if (target._isScroller) {
      // If it is a scroll container, allow the event to pass to enable internal scrolling
      return;
    }
    target = target.parentNode;
  }
  // If it is not a scroll container, prevent default behavior to avoid overall WebView dragging
  e.preventDefault();
}, { passive: false }); // Note: passive: false must be set, otherwise preventDefault may be invalid

Notes: In the third parameter of addEventListener, passive: false is crucial. In iOS 11 and above versions, Safari sets the passive of the touchmove event to true by default to optimize scrolling performance, at which point preventDefault() will be invalid. Therefore, passive: false must be explicitly set to ensure that preventing the default behavior takes effect.

Solution 2: Compromise Design to Convert Blank Areas into Functional Interactions

In some scenarios, completely preventing the dragging behavior of the WebView may conflict with the operating habits of iOS users (iOS users are accustomed to the "pull-down rebound" interaction). At this time, we can change our thinking - instead of deliberately eliminating the blank area, we "decorate" it into a useful function and turn the problem into an experience optimization point.

1. Core Idea: Use Blank Areas to Carry Interactive Functions

The "pull-down rebound" feature of iOS itself has a certain user cognitive basis, and we can design functional operations based on this, such as:

• Pull-down to refresh: Combine the top blank area with the "pull-down to refresh" function. When the user pulls down to expose the blank area, trigger the page refresh logic, and the blank area can display prompt text such as "Pulling down to refresh..." or loading animations to replace the monotonous white color.
• Pull-up to load more: When the user pulls up to expose the bottom blank area, trigger the load-more logic of the list, and the blank area displays the prompt "Loading...".
• Branded decoration: Set the blank area to a color consistent with the brand style, add a brand logo or simple patterns, so that the blank area is integrated into the page design instead of being an obtrusive "flaw".

2. Implementation Example: Combination with Pull-Down to Refresh Function

Taking the common pull-down to refresh as an example, it can be implemented with third-party libraries (such as iscroll, better-scroll) or native JavaScript. The core logic is to monitor the pull-down distance of the page, trigger the refresh logic when the distance reaches the threshold, and display a status prompt in the top blank area.

let startY = 0; // Y coordinate when touch starts
let pullDistance = 0; // Pull-down distance
const refreshThreshold = 50; // Threshold distance to trigger refresh
const refreshContainer = document.getElementById('refresh-container'); // Top prompt container

// Listen to touchstart event to record initial position
document.body.addEventListener('touchstart', function(e) {
  startY = e.touches[0].clientY;
});

// Listen to touchmove event to calculate pull-down distance and display prompt
document.body.addEventListener('touchmove', function(e) {
  const currentY = e.touches[0].clientY;
  pullDistance = currentY - startY;
  
  // Display top prompt when the page is at the top and pull-down distance is positive
  if (pullDistance > 0 && document.documentElement.scrollTop === 0) {
    e.preventDefault(); // Control pull-down speed to avoid excessive rebound
    refreshContainer.style.height = `${pullDistance}px`;
    if (pullDistance > refreshThreshold) {
      refreshContainer.textContent = 'Release to refresh';
    } else {
      refreshContainer.textContent = 'Pull down to refresh';
    }
  }
}, { passive: false });

// Listen to touchend event to judge whether to trigger refresh
document.body.addEventListener('touchend', function() {
  if (pullDistance > refreshThreshold) {
    refreshContainer.textContent = 'Refreshing...';
    // Trigger refresh logic
    fetchData().then(() => {
      // Reset after refresh is completed
      refreshContainer.style.height = '0px';
      pullDistance = 0;
    });
  } else {
    // Reset rebound if threshold is not reached
    refreshContainer.style.height = '0px';
    pullDistance = 0;
  }
});

The advantage of this solution is that it conforms to the operating habits of iOS users, turns the original "problem" into a function that improves the user experience, and avoids complex event control logic at the same time, making it suitable for content list pages.

IV. Solution Selection: Decision-Making Based on Scenarios

The two solutions are applicable to different business scenarios, and developers can choose according to actual needs:

• If the page has a "fixed layout" (such as a login page, a detail page) and no internal scrollable elements, Solution 1 is recommended to completely eliminate the blank area problem and ensure the integrity of the page.
• If the page is a "content scrolling type" (such as a list page, an information page) and needs to take into account user operating habits, Solution 2 is recommended to convert the blank area into functional interactions and improve the user experience.

V. Summary

The white blank area issue when pulling iOS web pages up and down is essentially due to insufficient understanding of the default behavior of WebView touch events. Whether it is precisely controlling events through preventDefault() or converting blank areas into functional interactions, the core is the balance between "complying with system characteristics" and "meeting business needs". In actual development, developers should first clarify the interactive scenarios of the page, then select an appropriate solution, and finally achieve an effect that both complies with system specifications and improves the user experience.