When a user changes the view inside an Ignition IFrame, the embedded page rewrites its own URL. That new URL stays inside the browser's child frame. Neither the Ignition component nor the Gateway receives it. A reliable capture has to come from one of two places: the embedded application reports its own URL, or Ignition builds the URL itself so it already holds the state. Reading the frame from the Ignition side works only in narrow same-origin cases.
Where does the current URL live after the user navigates inside the frame?
Follow a single user click through the system. The frame's source URL loads a document into a separate browsing context, the child window. From that point, every click, filter change, or zoom happens inside the child window. The embedded application appends its state parameters to the child window's location, either with a real navigation, a fragment change, or a history API rewrite. The source attribute on the parent's frame element keeps its original value. It records what was loaded first, not what is showing now.
| Hop | What carries the request | Sees the updated URL? |
|---|---|---|
| User input to embedded page | Browser events inside the child window | Yes, the child window location |
| Child window to parent page | Nothing by default. The browser isolates the child document. | Only if same-origin, or the child posts it out |
| Parent frame element | Source attribute set by Ignition | No. It stays at the initial value. |
| Ignition component property | Session sync to Gateway | No. It mirrors what Ignition wrote, not the child's location. |
| Gateway | HTTP from clients | No. The Gateway never sees the client's rendered DOM. |
This hop table rules out scraping. If the Gateway requests the page over HTTP, for example from a Web Dev module script, it gets a fresh copy with the default state. It cannot see the document the user is looking at.
Check 1: Is the frame in a Perspective session or a Vision client?
Open the view in the Designer and identify the component.
- Perspective inline frame. The frame is a standard HTML iframe inside the user's browser. Browser security rules decide everything that follows. Go to Check 2.
- Vision web browser component. The embedded browser runs inside the Java client, so browser same-origin rules between Ignition and the page do not apply in the same way. Open the component's property list and its scripting reference in the Vision component documentation. Look for a current-location property or a navigation event. If one exists, bind or script it into your storage location, then go straight to the verification section. If none exists, continue at Check 3.
Check 2: Does the embedded page share the parent's origin?
The browser allows script in the parent page to read the child window's location only when both documents share the same scheme, host, and port. Compare the Perspective session URL with the embedded page URL field by field:
| Field | Perspective session | Embedded page | Must match for parent read access |
|---|---|---|---|
| Scheme | http or https | http or https | Yes |
| Host | Gateway hostname | Web app hostname | Yes, exact string. An IP address and a hostname do not match. |
| Port | Gateway web port | Web app port | Yes |
If any field differs, a read attempt from the parent throws a security error in the browser console. There is no Ignition setting that bypasses this rule. Even when the origins match, Perspective does not give you a supported place to run arbitrary client-side script in the parent page. A same-origin reverse proxy therefore removes only half the obstacle. In either outcome, continue to Check 3.
Check 3: Can you modify or configure the embedded web application?
This check decides between the two workable designs.
- Yes, you control the page's code. Have the page report its own location to the Gateway every time its state changes. This design is described in the next section.
- No, but the application stores per-user state or exposes an API. Use that mechanism instead. Reopen the page with the application's own saved-view link or its restore endpoint, and store only that identifier in Ignition.
-
No, it is a closed third-party page. Move the controls into Ignition. The application already encodes its state as appended URL parameters, so Ignition can build the URL itself:
- Record which query or fragment parameters change for each user action. Use the page outside Ignition and compare copied URLs.
- Create Ignition inputs, such as dropdowns, date pickers, or toggles, for those parameters. Hide or ignore the equivalent controls inside the embedded page.
- Build the frame's source URL from the base URL plus those inputs with an expression or script binding.
- Persist the input values per user, for example in a database table keyed on username. Rebuild the URL from them when the view opens.
How do you wire the embedded page to report its URL to the Gateway?
The data path becomes: embedded page in the browser, then an HTTP POST to a Gateway endpoint, then per-user storage, then a read-back into the frame source when the view opens.
- Create an HTTP endpoint on the Gateway with the Web Dev module. It accepts a POST containing a user key and a URL, and writes them to a database table or a per-user tag. Copy the endpoint's full Gateway URL from the resource path.
- Give the page an identity. Append a user key parameter, with a name of your choosing, to the source URL that Ignition sets, and have the page read it back. Confirm first that the application tolerates an unknown parameter.
- Add the reporting hook to the embedded page:
- Allow the cross-origin call. The page and the Gateway are on different origins, so the endpoint response must include an Access-Control-Allow-Origin header naming the embedded page's origin. A text/plain body keeps the request simple and avoids a CORS preflight.
- Restore the stored URL on view open only. Read it once in a startup script or a non-polling query binding, and write it to the frame source. Do not bind the source live to the stored value.
| Pitfall | Symptom | Correction |
|---|---|---|
| Live binding from storage to frame source | The frame reloads after every user change, which can loop | Load the stored URL only when the view opens |
| One memory tag for all users | Users restore each other's views | Key the storage on username or the user key parameter |
| Session-scoped storage | State is lost at logout or session timeout | Persist to a database table or per-user tag |
| App routes with the history API only | No reports reach the Gateway | Call the report function from the app's route-change hook |
| URL carries auth tokens | Credentials are stored in plaintext | Strip token parameters before storing |
How do you confirm the stored URL restores the exact view?
- Open the Ignition view with browser developer tools open on the Network and Console tabs.
- Change the state inside the frame. Confirm a POST to the Gateway endpoint returns 200, and that the console shows no CORS or security errors.
- Query the storage table or tag. Confirm the stored URL matches the child window's current URL, including every appended parameter.
- Log in as a second user and change state. Confirm the first user's record is unchanged.
- Navigate away from the view and reopen it. Confirm the frame loads the stored URL exactly once, with no reload loop in the Network tab.
- Close the session completely, start a new one, and open the view. Confirm the embedded page opens on the same filters and position the user left, not the default page.
FAQ
What happens if I read the IFrame source property after the user navigates?
You get the URL Ignition originally loaded. Navigation inside the child frame never writes back to the parent's frame element or to the Ignition component property.
What happens if the embedded page is on a different host or port than the Ignition Gateway?
The browser blocks the parent page from reading the child window's location and throws a security error. Capture has to come from the embedded page posting its own URL, or from Ignition building the URL itself.
What happens if I use the Web Dev module to scrape the page HTML?
The Gateway fetches a fresh copy of the page in its default state. It cannot see the document rendered in the user's browser. Use the Web Dev module instead as a receiving endpoint that the embedded page posts its URL to.
How do I stop the IFrame reloading every time the stored URL updates?
Write the stored URL to the frame source only once, when the view opens, using a startup script or a non-polling binding. A live binding between storage and the source forces a reload on every reported change.