Opened 3 years ago

Closed 3 years ago

#16963 closed bug (fixed)

Gerrit broken in safari and webpositive

Reported by: nephele Owned by: kallisti5
Priority: high Milestone: R1/beta3
Component: Website/Gerrit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Since the recent gerrit update I am unable to use it on my phone (safari) and on WebPositve anymore.

In WebPositive the site remains completely blank.

In safari the page looks nicer now, but will redirect/reload on clicking single items which doesnt match what it did before, which also breaks the safari back behaviour (swipe to the left) and most of the time plainly breaks with safari showinf"a problem repeatedly occured". I have been able to show a gerrit change once with safari since the update.

Change History (27)

comment:1 by bitigchi, 3 years ago

Also on the latest Safari it leaks memory. I get the "This website is eating your memory, consider closing this tab" error each time I open Gerrit.

Last edited 3 years ago by kallisti5 (previous) (diff)

comment:2 by kallisti5, 3 years ago

We upgraded from Gerrit 3.0 to 3.2.10 which seemed to cause this.

It really isn't a bug on our end, and represents rendering issues within Gerrit's new UI in some browsers. I've noticed issues around the UI "reloading" while typing comments resulting in unexpected backspace presses ending in navigating away from the page.

I can try upgrading to Gerrit 3.3.0, however that may not fix it.

I'd recommend raising these issues to Gerrit directly. We can't remain on 3.0 since it uses an old authentication method github will no longer support in the future.

comment:3 by kallisti5, 3 years ago

Also, i'm still fighting bugs in the 3.2 upgrade... our hook scripts no longer run because their "internal" plugin activation process is pretty unclear.

comment:4 by nephele, 3 years ago

With haikuwebkit on the dark mode commit i can use the site fine, I will see if this is also the case for HEAD of haikuwebkit (but probably only next week).

comment:5 by nephele, 3 years ago

I would like to add that gerrit 3.4 has been released aswell.

in reply to:  4 comment:6 by pulkomandy, 3 years ago

Replying to nephele:

With haikuwebkit on the dark mode commit i can use the site fine, I will see if this is also the case for HEAD of haikuwebkit (but probably only next week).

With the current version I'm working on it seems to crash, but surely that will solve itself in the next merge of WebKit changes.

For problems with Safari there is not a lot we can do, and the problem can be reported to Gerrit developers.

Possibly related bug at Gerrit: https://bugs.chromium.org/p/gerrit/issues/detail?id=13040&q=safari&can=2

comment:7 by nephele, 3 years ago

Installing the firefox browser on iOS seems to work as a workaround, since it also uses webkit it is possibly a safari specific bug.

No change in the behaviour for ios 14.6.

this also occurs on https://chromium-review.googlesource.com/ which reports gerrit 3.4, so it is unlikely that updating gerrit at this time would resolve this.

comment:8 by madmax, 3 years ago

Removing the calls to window.performance.measure (2) and window.performance.mark (1) in polygerrit_ui/elements/gr-app.js from var/gerrit/gerrit.war seems to make WebPositive work.

comment:9 by pulkomandy, 3 years ago

I am confused, because this appears to be implemented in WebKit and not guarded by a compile time or runtime option: https://github.com/haiku/haikuwebkit/blob/main/Source/WebCore/page/Performance.cpp#L340

comment:10 by madmax, 3 years ago

FWIW, I've updated and tested again. hrev55135 64bits. WebPositive about window says HaikuWebKit 1.7.0 (the package is 1.7.1, though) and WebKit 610.1.9.

Loading the main page without changes leaves a pair of: "TypeError: window.performance.measure is not a function. (In 'window.performance.measure(e)', 'window.performance.measure' is undefined)" messages in the JS console.

Removing those calls and restarting gerrit I can load the main page, but get the same error for 'window.performance.mark' when trying to load a change.

Removing also that call loads the change view without JS errors.

comment:11 by madmax, 3 years ago

Maybe something with the IDL or however those methods are exported to JS objects?

In case it was due to some overriding or whatever tricks in gerrit, I tried with a local empty page. navigation, timing and now are there; mark, clearMarks, measure, clearMeasures, getEntries, getEntriesByType, getEntriesByName, clearResourceTimings and setResourceTimingBufferSize are not.

comment:12 by X512, 3 years ago

Any chance to quickly fix this? I currently have no access to Gerrit from Haiku, both WebPositive and Otter don't work. I currently use tablet PC with Windows and Firefox to access Gerrit.

comment:13 by kallisti5, 3 years ago

Nope.. the quickest path to fixing it is getting the webkit 2 changes integrated by branching R1/Beta3 and updating our haikuports builders.

All new versions of gerrit show this issue in Webpositive. We can't downgrade since the update was forced by the oauth changes in gerrit / github.

https://ens.domains and https://app.ens.domains also breaks with webpositive. We just *really* need to get the webkit 2 changes in place.

comment:14 by pulkomandy, 3 years ago

The current build of HaikuWebKit is crashing when loading Gerrit. So that's not really helpful.

Also, why are you mentioning webkit2? The webkit2 branch is not even compiling at the moment, and switching to webkit2 will not fix anything, it is just a different API over the same engine.

To access Gerrit from Haiku until web browsers are fixed, it should be possible to use gertty, which is an ncurses interface to Gerrit. No web browser needed then. I packaged it some time ago but it needs an update to run with current Python versions (the package is for Python 3.6). Also at the time I had not found how to set up the github authentication with it.

https://ens.domains and ​https://app.ens.domains also breaks with webpositive. We just *really* need to get the webkit 2 changes in place.

Please make separate bugreports.

comment:15 by kallisti5, 3 years ago

Also, why are you mentioning webkit2? The webkit2 branch is not even compiling at the moment,

Maybe it's time to get the webkit roadmap down on paper somewhere :-)

comment:16 by pulkomandy, 3 years ago

There is no roadmap. There is only me merging changes from upstream and trying to keep things compiling. No other work is being done.

comment:17 by nephele, 3 years ago

I agree, this issue is unrelated to webkit2. Also updating haikuwebkit won't make this work in safari either, if these above mentioned calls can be removed as a workaround that sounds like the better option to me?

comment:18 by X512, 3 years ago

This command from Terminal work for me: ssh git.haiku-os.org gerrit query status:open.

comment:19 by pulkomandy, 3 years ago

Gerrit working again on haikuwebkit 1.8.1.

Any news about Safari? Probably that bug should be reported to Gerrit and/or Safari developers?

comment:20 by nephele, 3 years ago

It is still partially broken on ios 14.6 Safari, but it does work on firefox for iOS (which uses webkit aswell afaik) so this may be a safari specific bug

Reporting to gerrit probably only makes sense if we update to a current version?

comment:21 by pulkomandy, 3 years ago

eporting to gerrit probably only makes sense if we update to a current version?

Gerrit 3.2 is not "end of life" at the moment (it will be when Gerrit 3.5 is released): https://www.gerritcodereview.com/releases-readme.html

So bugreports for it will be accepted.

comment:22 by cocobean, 3 years ago

https://review.haiku-os.org/ is currently running Gerrit 3.2.10. Gerrit 3.2.11 is current.

Possibility, bump to Gerrit 3.2.11 and build a test instance of Gerrit 3.4.4 for test review with haikuwebkit 1.8.1?

Note: Safari/macOS 11.4 (desktop) - Haiku Gerrit 3.2.10 seems to work fine even when I logged in to view tickets.

Last edited 3 years ago by cocobean (previous) (diff)

comment:23 by pulkomandy, 3 years ago

There are no problems with haikuwebkit 1.8.1. The remaining problem is with Safari on iOS, only.

comment:24 by Coldfirex, 3 years ago

Looks like this ticket can be closed then.

comment:25 by nephele, 3 years ago

The issue in safari iOS still remains, and I'd argue beeing able to read code on my phone should work. :)

comment:26 by Coldfirex, 3 years ago

Doh, sorry. Just assumed this was a webkit ticket.

comment:27 by pulkomandy, 3 years ago

Milestone: UnscheduledR1/beta3
Resolution: fixed
Status: newclosed

I think the Safari issue should be reported to either Gerrit developers or Safari developers. There is nothing we can do about it from our side.

Note: See TracTickets for help on using tickets.