The ISP (here, the WiFi hotspot) is what delivers pages to you. It's of course trivial for an ISP to read unsecured traffic:
Let's now consider a case where the credential submission is secured with HTTPS (so the ISP cannot sniff them right off the wire), but the HTTPS log-in page loads an unsecured script,
helper.js. The ISP can inject any behavior into that non-HTTPS script before it finally serves the script to the browser. For example, the ISP can inject the instructions, "When this page submits credentials, send a copy of them to
evil.example.com." The diagram below shows secured requests and responses in green and insecure requests/responses in other colors:
When your browser requests
helper.js over HTTP, the malicious ISP responds with a resource that has the wrong content. Your browser has no idea what
helper.js should look like, and without any integrity validation measure (like HTTPS), the browser has no idea anything is wrong. Your browser assumes it has correctly been served
http://tmail.com/helper.js, because that's what it asked for and the ISP sent back a response without any complaint (e.g., the response was an HTTP
/helper.js). The fact that what your browser got is different from what the real server sent is totally irrelevant, because your browser has no way to detect that this difference occurred.
Based on your comments, you seem to think that modifying a resource can only be done by redirecting the browser to another resource. This is incorrect. Consider Bob the browser, Iggy the ISP, and two servers, Alice and Mallory.
First, consider the honest case:
Now let's consider a dishonest case:
In this case, the browser's address bar would be different from what you originally typed in:
mallory.com/favoritefood instead of
Now consider this case instead:
There's no other resources involved.
http://alice.com/favoritefood is the only resource being fetched here; Iggy simply lied about what the contents of the resource were. There is no way for Bob to detect that Iggy is lying, because there is no integrity-validating system in place.
One final attempt at explanation: suppose the ISP is honest but mistakenly flipped a single bit when delivering the contents of the HTML file. Surely you would not expect such a mistake to cause the web page to load under a different domain. Now suppose that the honest ISP mistakenly flipped two bits instead of just one: again, such a mistake would never cause the domain or resource path to change. Now suppose the ISP flipped two thousand bits by honest mistake (perhaps the ISP has a faulty switch some place, or the WiFi router was hit by cosmic rays): again, no need for the domain to change. Now suppose the change was done maliciously instead of by mistake: again, the change in intent causes no change in what is actually happening. The resource path and origin, as identified in the browser's address bar, remains unchanged, while the ISP is free to change the contents of the resource (honestly or dishonestly) without detection.