Steps to reproduce: A) 1. create an account on Duolingo and complete the tutorial B) 1. log in with an existing account. Result: Only the background and the menus are shonw Expected result: A floating frame with the course status.
Created attachment 216714 [details] the page is rendered correctly using chromium
Created attachment 216715 [details] page is not rendered right with epiphany this is also shown using minibroswer and gtklauncher using current master
Some errors on the console: [Error] TypeError: undefined is not an object (evaluating 'duo.user.get') (anonymous function) (all.js, line 78) [Error] ReferenceError: Can't find variable: chrome render (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 467) switchView (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 191) home (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 898) (anonymous function) (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 271) (anonymous function) (anonymous function) (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 277) some any (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 226) loadUrl (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 277) loadUrl (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 905) start (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 276) (anonymous function) (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 902) t (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 66) fireWith (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 67) ready (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 56) K (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 65) It looks like the page is looking for Chromium specific (!) variables in the window object.
> It looks like the page is looking for Chromium specific (!) variables in the window object. Yes, as the minibrowser and gtklaunch sets as user-agent "Chrome" (among others) a js script assumes it is a chromium browsers and calls a chromium specific variable (yeah). As a workaround, if we remove the Chrome thing in the user-agent string, the page is rendered normally. So, I don't think this is WebKit bug, but a bug in the js script, or perhaps (maybe) in the browser, which uses that user-agent.
(In reply to comment #4) > So, I don't think this is WebKit bug, but a bug in the js script, or perhaps (maybe) in the browser, which uses that user-agent. We may need to think of a workaround. Clearly there are problems with pretending to be Chromium. We may need to start pretending to be OS X Safari.
(In reply to comment #5) > (In reply to comment #4) > > > So, I don't think this is WebKit bug, but a bug in the js script, or perhaps (maybe) in the browser, which uses that user-agent. > > We may need to think of a workaround. Clearly there are problems with pretending to be Chromium. We may need to start pretending to be OS X Safari. Agree specially after the fork, engines might start to diverge quickly.
Created attachment 216802 [details] Patch
Comment on attachment 216802 [details] Patch We can't just claim to be Safari. We need to claim to be Safari on OS X. It's in the comment! :)
(In reply to comment #8) > (From update of attachment 216802 [details]) > We can't just claim to be Safari. We need to claim to be Safari on OS X. It's in the comment! :) I don't understand why we need to say we are running OS X. Do you mean something like this: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.13+ (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2 from here: http://www.useragentstring.com/pages/Safari/
(In reply to comment #9) > Do you mean something like this: > Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.13+ (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2 from here: http://www.useragentstring.com/pages/Safari/ Yes. When we claim to be Safari on Linux, some sites assume that Safari && !OSX is Safari && iOS. iOS pages are often light-weight versions that aren't suitable for desktop display or are missing resources such as custom fonts.
(In reply to comment #10) > (In reply to comment #9) > > Do you mean something like this: > > Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.13+ (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2 > from here: http://www.useragentstring.com/pages/Safari/ > > Yes. When we claim to be Safari on Linux, some sites assume that Safari && !OSX is Safari && iOS. iOS pages are often light-weight versions that aren't suitable for desktop display or are missing resources such as custom fonts. AAAhhh..the comment in code was a @TODO ... roger that!
(In reply to comment #11) > AAAhhh..the comment in code was a @TODO ... roger that! Not really a TODO. We had essentially two choices: we could either claim to be Safari + OS X or Chromium on the proper operating system. The previous version just claimed to be Safari on Linux, which led to issues. The comment tried to explain the situation.
Created attachment 217303 [details] Patch
Comment on attachment 217303 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=217303&action=review > Source/WebCore/platform/gtk/UserAgentGtk.cpp:47 > +#if CPU(PPC) || CPU(PPC64) > +#define PROCESSOR "PPC" > +#elif CPU(X86) || CPU(X86_64) > +#define PROCESSOR "Intel" > +#elif CPU(ARM) || CPU(ARM64) > +#define PROCESSOR "ARM" > +#else > +#define PROCESSOR "Unknown" > +#endif I'd rather this be a function than a preprocessor definition. Perhaps something like "cpuDescriptionForUSAString" > Source/WebCore/platform/gtk/UserAgentGtk.cpp:74 > +#elif OS(DARWIN) || OS(UNIX) > + uaOSVersion = String(PROCESSOR " Mac OS X"); > #else I think a small comment here could be useful. We need to explain that Linux+Safari triggers the iOS path on some websites.
Created attachment 217431 [details] Patch
Comment on attachment 217431 [details] Patch Okay. We need to test this *very thoroughly* before releasing it.
(In reply to comment #16) > (From update of attachment 217431 [details]) > Okay. We need to test this *very thoroughly* before releasing it. I'll commit it. But I have no idea how to test it. Do you mean to see the user experience in a ton of real websites?
Comment on attachment 217431 [details] Patch Clearing flags on attachment: 217431 Committed r159572: <http://trac.webkit.org/changeset/159572>
All reviewed patches have been landed. Closing bug.
(In reply to comment #17) > (In reply to comment #16) > > (From update of attachment 217431 [details] [details]) > > Okay. We need to test this *very thoroughly* before releasing it. > > I'll commit it. But I have no idea how to test it. Do you mean to see the user experience in a ton of real websites? Yep. Exactly. We need to ensure that this doesn't introduce more problems than it solves. User agents are very delicate.
Running Fedora 20 with epiphany-3.10.3 / webkitgtk3-2.2.3, and Amazon's cloud reader at https://read.amazon.com now throws up an unsupported browser page. It lists acceptable browsers as: Chrome 20+ Safari 5+ Firefox 10+ IE 10+ I'm not sure when this change made it into Fedora, but I've been running 20 since alpha, and I know the site was working as of a few weeks ago.
(In reply to comment #3) > Some errors on the console: > > [Error] TypeError: undefined is not an object (evaluating 'duo.user.get') > (anonymous function) (all.js, line 78) > [Error] ReferenceError: Can't find variable: chrome > render (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 467) > switchView (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 191) > home (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 898) > (anonymous function) (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 271) > (anonymous function) > (anonymous function) (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 277) > some > any (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 226) > loadUrl (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 277) > loadUrl (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 905) > start (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 276) > (anonymous function) (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 902) > t (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 66) > fireWith (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 67) > ready (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 56) > K (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 65) > > It looks like the page is looking for Chromium specific (!) variables in the > window object. Martin, my worry is that if we put Chromium in the user agent by default, we'll have similar issues on various sites. I've never seen something like this occur without Chromium in the UA.
(In reply to comment #22) > (In reply to comment #3) > > Some errors on the console: > > > > [Error] TypeError: undefined is not an object (evaluating 'duo.user.get') > > (anonymous function) (all.js, line 78) > > [Error] ReferenceError: Can't find variable: chrome > > render (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 467) > > switchView (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 191) > > home (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 898) > > (anonymous function) (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 271) > > (anonymous function) > > (anonymous function) (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 277) > > some > > any (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 226) > > loadUrl (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 277) > > loadUrl (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 905) > > start (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 276) > > (anonymous function) (f5c9405066ce187ddd25fa480d65fd02_mv_.min.js, line 902) > > t (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 66) > > fireWith (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 67) > > ready (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 56) > > K (1b104f59bca045b5837b0eb7f0d6de09_mv_.min.js, line 65) > > > > It looks like the page is looking for Chromium specific (!) variables in the > > window object. > > Martin, my worry is that if we put Chromium in the user agent by default, > we'll have similar issues on various sites. I've never seen something like > this occur without Chromium in the UA. I guess we can always try to file a bug with Typescript and hope for the best. :)
(In reply to comment #23) > I guess we can always try to file a bug with Typescript and hope for the > best. :) Sorry. I meant "TypeKit" here.