The CloudShell on Google Cloud Platform does not load (prompt missing)
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
Webcompat Priority | P2 |
People
(Reporter: hus787, Unassigned)
References
(Depends on 1 open bug, Regression, )
Details
(Keywords: regression, Whiteboard: [webcompat])
Attachments
(3 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:65.0) Gecko/20100101 Firefox/65.0 Steps to reproduce: Click on the Activate Cloud Shell on the Google Cloud Platform console. Actual results: The Cloud shell opens, loads but then does not show the shell prompt. Expected results: Shell prompt should work as it does on Firefox 63. CloudShell breaks in both Firefox 64 and 65
Comment 1•2 years ago
|
||
Regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=982f91f69b39773ac302d4d01610de1414894529&tochange=70f63648a0f6cf738d5555eb347986d7323ef16e Seems like bug 1497126 introduced this regression.
Updated•2 years ago
|
Comment 3•2 years ago
|
||
> Click on the Activate Cloud Shell on the Google Cloud Platform console.
I don't have a cloud google service. I don't have any shell to activate. Can somebody give me valid account or tell me the fastest way to reproduce this issue? Adrian, can you help me here?
Comment 4•2 years ago
|
||
Sure, you can use your mozilla account - just ignore all try for free messages and proceed to the login) https://accounts.google.com/signin/v2/identifier?passive=true&continue=https%3A%2F%2Fcloud.google.com%2Fcloud-console%2F%3Frefresh%3D1&service=cloudconsole&flowName=GlifWebSignIn&flowEntry=ServiceLogin
Comment 5•2 years ago
|
||
Thanks, Adrian! baku, this seems like a not great regression so I'll assign it to you and mark it P1.
Updated•2 years ago
|
![]() |
||
Comment 7•2 years ago
|
||
[Tracking Requested - why for this release]: Bad regression, major site.
Comment 8•2 years ago
|
||
adrian_sv, I'm not able to reproduce the issue anymore with the latest nightly. Can you confirm this?
Comment 9•2 years ago
|
||
Please bisect the fix too if indeed this is fixed.
Reporter | ||
Comment 10•2 years ago
|
||
This bug, as has been reported, has been fixed. I can now see work with the cloud shell but I think the underlying problem is still present because when I try the ssh connect to an instance from the web it has the same symptoms which are reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1513568 To reproduce, create an instance on GCP (would need to add billing info for that I guess) and click the ssh button of that instance. I have the video of it but can't upload it here.
Comment 11•2 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #9) > Please bisect the fix too if indeed this is fixed. It seems been fix by the server side. I cannot reproduce this issue also using a 2 months old nightly.
Reporter | ||
Comment 12•2 years ago
|
||
baku, you could still reproduce the problem in an instance's ssh console as I have described above (comment 10). If creating a billing account on gcp is not convenient, I could try to create a project and invite a developer to it so that they can easily work on this.
Comment 13•2 years ago
|
||
> If creating a billing account on gcp is not convenient, I could try to
> create a project and invite a developer to it so that they can easily work
> on this.
If this is OK for you, I just need to check why this happens to propose a solution. Yes, please.
Reporter | ||
Comment 14•2 years ago
|
||
:baku please check your email.
Comment 15•2 years ago
|
||
Removing the NI, since I see Hussain already helped on the required additional investigation and it seems you need billing info for GCP.
Reporter | ||
Comment 16•2 years ago
|
||
Please somehow snapshot the page so that it's reproducible even if the server response is changed. Would love to know how the snapshot was take too :D
Reporter | ||
Comment 17•2 years ago
|
||
The above mentioned (ssh through web console) is now fixed as well. I hope that too was not a server-side fix.
Reporter | ||
Comment 18•2 years ago
|
||
More info: Although the ssh console now work. But it's very unstable e.g. if we paste some command (git clone ...) in the terminal the terminal blacks out. Some random keystrokes bring it back and you can we that the command hasn't been executed.
Comment 19•2 years ago
|
||
Hussain, can you check if the issue goes away when disabling anti-tracking?
You can do it on about:preferences#privacy or setting network.cookie.cookieBehavior to 0.
Thanks for helping with the debugging of this bug.
Reporter | ||
Comment 20•2 years ago
|
||
Just checked. Disabling anti-tracking didn't help.
Comment 21•2 years ago
|
||
It's too late for 64 now.
Comment 22•2 years ago
|
||
Seems very unlikely to make 65 at this point, though I'd consider a low-risk patch as a dot release ride-along if one is available.
Comment 23•2 years ago
|
||
Hey :baku, how's this looking? should we still be tracking for 66?
Updated•2 years ago
|
While this isn't a new problem in 66 I notice we have at least one duplicate report. It might be affecting many users, so, if we do land a fix I'd be inclined to uplift as far as we think is safe.
Comment 25•2 years ago
|
||
I have no news here. Is there any chance that somebody else jumps on this bug? It's a P1 but I don't know exactly when I have time to work on it.
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Comment 26•2 years ago
|
||
Hsin-Yi - Based on Comment 25, can we try to find a new owner? Thanks in advance.
Comment 27•2 years ago
|
||
I'm exploring the alternative. Will get back here.
Comment 28•2 years ago
|
||
Karl, can you help me to debug this issue? I don't understand why enabling 2 nested iframes with the same URL breaks that website. I'm NI-ing you because this could be a webcompact issue. Thanks.
![]() |
||
Comment 29•2 years ago
|
||
We have a lot of issues related to this site not all the same, often closed because lack of details or fixed in release. The site seems also very sensitive to CSP, and any kind of blockers.
This looks like the same issue which was reported on October 2018 in https://webcompat.com/issues/20551
We had also for this site.
SSH blocking
- https://webcompat.com/issues/20551
Dupe of https://webcompat.com/issues/20505
which was itself dupe of https://webcompat.com/issues/15089 closed as worksforme by denschub - https://webcompat.com/issues/21295
We had also
https://webcompat.com/issues/9716 (with a lot of duplicates) which was investigated by Thomas Winiewski
The issue was for this one an incorrect use of the Performance Observer API and it has been fixed.
Google Engineers were super responsive in that bug.
Was related to Bug 1398477 probably
Maybe also https://webcompat.com/issues/20551
Form password issue
Text input
I will transfer this issue to Thomas or Dennis, who have already investigated it in the past.
Updated•2 years ago
|
Following up in email.
Tom is going to look into this, but it seems unlikely we'll be aiming to fix this for 66. We could still take a patch for 68 and potentially uplift to 67, though.
Updated•2 years ago
|
Comment 32•2 years ago
|
||
Hussain, can you verify that this is working now? I've tested in 67 Beta and 68 Nightly.
Comment 33•2 years ago
|
||
Aw crud, I didn't follow the STR correctly. I still get "Connecting: Provisioning your Google Cloud Shell machine...".
Back over to you Tom.
Tom is about to be on pto so I'm marking this fix-optional for 67 and we can aim for a fix in 68.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 35•2 years ago
|
||
Huh, I just tried this again and it worked. Then I tried one more time and it failed with a blank screen and a JS error in the console: "TypeError: this.screen_ is undefined". So it seems the problem is intermittent.
Comment 36•2 years ago
|
||
The error seems to be in the hterm.js component, and I can reproduce it by simply going the project page at https://hterm.org/ which is a live instance of the terminal emulator. Sometimes it works, sometimes it doesn't. Enabling network throttling in devtools seems to make it happen more often.
Comment 37•2 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 38•2 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Comment 39•2 years ago
|
||
I just tested this on Firefox 64.0.2 on Linux and OSX (also the current nightly on Linux) and I was able to get into my shell console just fine. I suspect that whatever broke it has since been fixed on Google's end. Mike, can you try again?
Comment 40•2 years ago
|
||
Tom, can you reproduce the issue described by Reuben in comment #36?
If I visit that site and refresh 10 or 15 times, it will reproduce. I see
TypeError: this.screen_ is undefinedhterm_all.js:10871:3
Breaking on hterm.ScrollPort.prototype.setBackgroundColor
(when it's not broken), this.screen_ is a custom element x-screen
.
Comment 41•2 years ago
|
||
On my nightly build I get a completely different an unrelated error on hterm.org which breaks the keyboard functionality (it doesn't happen in Chrome):
TypeError: this.scrollPort_.getDocument(...) is null hterm_all.js:12756:50
installKeyboard https://hterm.org/dist/1.84/hterm_all.js:12757
setupHterm https://hterm.org/index.js:157
initNext https://hterm.org/dist/1.84/hterm_all.js:172
wrapperGenerator https://hterm.org/dist/1.84/hterm_all.js:1755
initOs https://hterm.org/dist/1.84/hterm_all.js:4782
That happens here:
hterm.Terminal.prototype.installKeyboard = function() {
this.keyboard.installKeyboard(this.scrollPort_.getDocument().body);
};
hterm.ScrollPort.prototype.getDocument = function() {
return this.document_;
};
Sure enough, the ScrollPort only seems to set its document_
in a function named paintIframeContents_
, which is being called too late in Firefox compared with Chrome (I've snipped some irrelevant lines from this code-fragment):
hterm.ScrollPort.prototype.decorate = function(div, callback) {
this.div_ = div;
this.iframe_ = div.ownerDocument.createElement('iframe');
div.appendChild(this.iframe_);
const onLoad = () => {
this.paintIframeContents_();
}
// Insert Iframe content asynchronously in FF. Otherwise when the frame's
// load event fires in FF it clears out the content of the iframe.
if ('mozInnerScreenX' in window) { // detect a FF only property
this.iframe_.addEventListener('load', () => onLoad());
} else {
onLoad();
}
}
I've confirmed that they need that work-around in Firefox, but doing so causes the ScrollPort's document_
to be not be set in time for the installKeyboard call. This error hits Firefox as far back as version 56, according to mozregression.
They would need to delay calls to installKeyboard
until after the ScrollPort
has been set up. For example, this quick hack lets me get to a usable state:
hterm.Terminal.prototype.installKeyboard = function() {
let doc = this.scrollPort_.getDocument();
if (!doc) {
setTimeout(() => { this.installKeyboard(); }, 100);
} else {
this.keyboard.installKeyboard(doc.body);
}
};
But it's still a different error than the screen_
one others were getting. However, this is the line of code that was being a problem for others:
hterm.ScrollPort.prototype.setBackgroundColor = function(color) {
this.screen_.style.backgroundColor = color;
};
And screen_
is also defined in paintIframeContents_
, so I suspect that it was breaking for similar reasons (the iframe wasn't loaded, so some of the ScrollPort's state wasn't set yet).
As such I wouldn't recommend they simply apply my above hack, but rather improve their loading code to wait for the iframe to be loaded in Firefox's case.
(For the record, I think they're working around bug 1493878).
At this point, is this actually a wontfix/incomplete that we could split into several different issues? It sounds like there may be several (smaller) problems than what the bug was originally filed for.
Comment 43•2 years ago
|
||
Yeah, we probably need a bug open against hterm before this one becomes actionable for Google. Tom, would you mind filing one?
Comment 44•2 years ago
|
||
Done. https://bugs.chromium.org/p/chromium/issues/detail?id=980671
I wonder if we should also try to bump the priority of bug 1493878?
Comment 46•1 year ago
|
||
Sent an email on our partner list pointing to this bug and the crbug.
Updated•1 year ago
|
Comment 47•1 year ago
|
||
Followed up on the mailing list.
This is now filed internally with Google (as of 9/26), so hopefully there will be some progress soon.
Followed up again on the moz-google discuss list.
The google dev is able to reproduce this on 60.9.0esr but not on 70.0.1. Adrian, would you mind testing this again with 70.0.1 and with the current ESR (68.2)?
Comment 52•1 year ago
|
||
I'm not able to reproduce on https://console.cloud.google.com/home/dashboard?project=tsci-241420&cloudshell=true anymore (I think? I reloaded 10 times and it worked each time, but I can reproduce the bug on the https://hterm.org/ home page (reproduced on the 7th load). Will follow up on the mailing list.
Reporter | ||
Comment 53•1 year ago
|
||
uBlock origin breaks the console otherwise it works on 72.
Comment 54•1 year ago
•
|
||
(In reply to Liz Henry (:lizzard) from comment #51)
The google dev is able to reproduce this on 60.9.0esr but not on 70.0.1. Adrian, would you mind testing this again with 70.0.1 and with the current ESR (68.2)?
It is WFM on Windows 7 Pro x32 , Windows 10 x64, Mac 10.14 with:
72.0a1 2019-11-06
70.0.1 2019-10-30
68.2.0esr 2019-10-16
FYI, this issue was initially covering the fact that the google console doesn't load at all, so that's what I've checked.
Also, I still see a CSP warning spamming the browser console:
Content Security Policy: The page’s settings observed the loading of a resource at eval (“script-src”). A CSP report is being sent. 11 m=cloudshell:45:55
AFAIK, seems to me this issue has been fixed - guessing on the google side? Should we mark it as such?
Updated•1 year ago
|
Comment 55•1 year ago
|
||
Yeah, let's close -- they said they would work on a workaround for 68. It seems like they have. Thanks!
Updated•1 year ago
|
Description
•