Open Bug 1844066 Opened 2 years ago Updated 2 years ago

Changing the src attribute of an IFRAME element that is added to the DOM creates a new history entry.

Categories

(Core :: DOM: Navigation, defect)

Desktop
Unspecified
defect

Tracking

()

People

(Reporter: daniel, Unassigned)

Details

Attachments

(1 file)

Steps to reproduce:

From javascript changing the src attribute.

document.querySelector('iframe').src = 'https://mozilla.org';

Actual results:

history.length = 3;

Expected results:

history.length = 2;

Hardware: Unspecified → Desktop

Minimal example:

<!DOCTYPE html>

<head>
    <title>BUG-1844066 test page</title>
</head>

<body>
    <div>
        <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1844066">BUG-1844066</a>
    </div>
    <iframe></iframe>
    <button>add frame</button>
    <script>
        const historyLength = history.length;
        document.querySelector('button').addEventListener('click', () => {
            const iframe = document.querySelector('iframe');
            iframe.onload = () => {
                console.assert(historyLength === history.length, 'history length changed!');
            }
            iframe.src = "https://mozilla.org";
        })
    </script>
</body>

Assert fails on iframe load (never mind the X-Frame-Options: DENY not showing the actual mozilla.org content).
Since this behaviour is

  • different on other browsers
  • has a (silly) workaround
    i think this should be filed as bug.

Workaround is to remove the iframe from the DOM before changing the source, and re-appending it after:

const historyLength = history.length;
document.querySelector('button').addEventListener('click', () => {
    const iframe = document.querySelector('iframe');
    iframe.onload = () => {
        console.assert(historyLength === history.length, 'history length changed!');
    }
    const span = document.createElement('span');
    iframe.replaceWith(span);
    iframe.src = "https://mozilla.org";
    span.replaceWith(iframe);
})

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

Jake diagram showing how the navigation and session history entries are currently generated versus "expected" behaviour.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Component: DOM: Core & HTML → DOM: Navigation
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: