Closed Bug 1283493 Opened 8 years ago Closed 8 years ago

Cannot Navigate Away From Webpage by Typing URL in Location bar

Categories

(Core :: DOM: Navigation, defect, P3)

47 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1263100

People

(Reporter: therubex, Unassigned)

References

()

Details

(Whiteboard: [DUPEME?])

URL: https://thelounge.github.io/ Click the demo link, 'Or try the demo'. This page opens, https://avatar.playat.ch:1000/ Type in the Location bar: https://www.mozilla.org Result: The page "refreshes" but remains at https://avatar.playat.ch:1000/ Expected: www.mozilla.org should load. If you check Error Console, you will see a "hit" to www.mozilla.org, but...
I suspect there's an older bug filed about this, but I can't find it atm.
Priority: -- → P3
Whiteboard: [DUPEME?]
Whiteboard: [DUPEME?] → [DUPEME?][fxsearch]
Obviously not a location bar bug. I can reproduce it using STR_2 (assuming comment 0 is STR_1) STR_2: 1. Open https://thelounge.github.io/ 2. Click on "demo" in string "Or try the demo" [to navigate to https://avatar.playat.ch:1000/] 3. Type "example.org" in searchbar (or external application like Notepad++) 4. Select the text typed in Step 3, then drag and drop it to the selected <tab> in Firefox AR: Page just reloads ER: Should navigate to http://example.org/ Notes: 1) This bug is probably using similar mechanism as described in bug 1263100, or even is a duplicate 2) It's possible that after several tries this bug will become not reproducible. In all such cases I can still reproduce it if web console (or any other developer tool) is open
Component: Location Bar → Document Navigation
Product: Firefox → Core
See Also: → 1263100
yep, you're right, I was looking for that bug.
Whiteboard: [DUPEME?][fxsearch] → [DUPEME?]
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
See Also: 1263100
(In reply to :Gijs Kruitbosch from comment #4) > > *** This bug has been marked as a duplicate of bug 1263100 *** I've read today that when user navigates from a page with socket, the socket is disconnected first. Therefore web developer who wrote that article had to use a timeout to avoid some bug in front-end. But it's possible to use "disconnect" event on socket as an analogue of "onbeforeunload". The page from comment 0 uses Socket.IO library, so this scenario is plausible. (I haven't checked it!) Somebody should check that socket scenario, but I don't have time to (create and) mess with a server Are you sure that it's indeed a duplicate of bug 1263100 in a sense that bug 1263100 will introduce some mechanism that would prevent both onbeforeunload and (possible)socket scenarios? Edited code from the article (https://habrahabr.ru/post/143162/): socket.on("disconnect", function () { // evil code written by arni2033 location.reload(); /** original good code: timeout is used in order not to notify user if he simply leaves the page setTimeout(function () { $("#sockstat").text("connection lost!"); }, 500); */ });
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to arni2033 from comment #5) > (In reply to :Gijs Kruitbosch from comment #4) > > > > *** This bug has been marked as a duplicate of bug 1263100 *** > > I've read today that when user navigates from a page with socket, the socket > is disconnected first. > Therefore web developer who wrote that article had to use a timeout to avoid > some bug in front-end. Which article? > But it's possible to use "disconnect" event on socket as an analogue of > "onbeforeunload". > The page from comment 0 uses Socket.IO library, so this scenario is > plausible. (I haven't checked it!) > Somebody should check that socket scenario, but I don't have time to (create > and) mess with a server > > Are you sure that it's indeed a duplicate of bug 1263100 in a sense that bug > 1263100 will introduce some mechanism that would prevent both onbeforeunload > and (possible)socket scenarios? I think if we fixed bug 1263100, it would involve breaking JS-based page navigation after beforeunload has fired (and the user has not said they want to stay on the page). That would include what the page in this bug is doing, which is calling location.reload() off the socket's disconnect handler (refresh() function in lounge.js), because it happens after beforeunload. In other words, yes, I think that any solution in bug 1263100 would also address this bug.
Flags: needinfo?(gijskruitbosch+bugs)
You need to log in before you can comment on or make changes to this bug.