Closed jondashkyle closed 6 years ago
Hey this is great! Thanks a bunch. Sorry it took so long for me to check it out. I've tested it on your branch and it seems to work, but for some reason I'm having issues like these:
– Preference can carry to new windows – Preference doesn't work on first window – Doesn't switch back to desktop site from website.com/mobile – Navigating to a different website still loads desktop
So, generally, it does what you'd think after a couple tries, but the behavior isn't consistent. Not sure how to approach this—did you run into any of these issues before?
Here's an alternative scenario:
– Use Request Mobile Site
as an action rather than a toggle
– Reset the UA often or only set it for one window and one website
That way you can just smash the shortcut to get a mobile redirect on a site you just loaded—maybe more forgiving?
Hey! Thanks for giving it a look. I could see this being an array of sites in your user preferences json
. Triggering the action adds or removes the site from that array. Having used this over the past two weeks I really do find it useful; having it reset or only applied per-window would be an annoyance.
mobile.nytimes.com
, as you point out. Unsure how we could elegantly resolve that.To summarize, the primary bug of requiring a new window to take effect can likely be resolved within toggleRequestMobile()
under /lib/components/view.js
. The functionality to toggle per-site and store in user preferences sounds useful!
Gotcha—my issue with “Navigating to a different website still loads desktop” was related to the original window bug, I think. Just got weirded out by the behavior of the thing.
Agree that the main issue is the UA spoofing not working on the app's first window.
Replacing load(webview.getURL())
with reload()
fixes this for me (don't ask me why). With that fix, we could make "Request Mobile Website" a global toggle (for all windows), and we'd be set, no?
On toggling off: looked into it a bit and it seems browsers like Chrome or Safari do more than switching UA + Refresh, though. They seem to remember what was your original request and can revert to that when disabling the browsing mode, except if you explicitly typed mobile.website.com
. Not sure we need all that, though.
reload()
fixes it! Was hoping it’d be a simple (although mysterious) one.I think that this is a nice first implimentation. Perhaps if there is a roadmap for additional functionality we could append that second note!
About those commits earlier: I couldn't find a way to enforce the UA on a window basis (once it's set on one webview, all other ones follow), so I made the changes to make it an app-wide parameter.
You can test it the following way:
– Open the app (with preference set to false
)
– Navigate to a wikipedia page or such
– Open a new window, navigate to twitter or such
– Toggle Request Mobile Site
on
– All windows will reload with the mobile version of the pages
– New windows will also load mobile versions
Disabling Request Mobile Site
roughly works as expected (disables UA on future requests and reloads current urls).
The key in oryoki-preferences.json
allow to start the app with the toggle on.
@jondashkyle Will let you have a look at it, and if that looks okay I'll merge into /dev.
This looks great! Clicked around a bit and was able to replicate everything you mentioned above. Seems good to me!
Is this already available in the 0.2.1
build?
I added "request_mobile_site" : true
(and tried with false
as well) in oryoki's json prefs but can't find the menu item under Tools
. Also after quitting and reopening the app.
Afraid you'd have to build from source on /dev
for this. I'd like to fix a few things before releasing 0.2.2, hopefully soon.
Thanks for replying, no problem! Could you point me out how to do it? Never built up an electron app from source.
I've added some instructions there: https://github.com/thmsbfft/oryoki/blob/dev/README.md#build-from-source
If you follow that from the dev
branch, you should be able to build. Not fully tested on that branch obviously, so things might break a bit. Hope this helps!
Working well! I'd suggest to add to the instructions for building the app from source, to add
git branch -a
git checkout dev
after you did git clone
.
Thanks!
Added that, thanks for the suggestion—and glad packaging worked out!
That was pretty easy. This creates the ability to set the useragent (UA) to load mobile sites. It does so by updating the
webview
’suseragent
. For a good example navigate to Twitter, The New York Times, Google or Github.A few things to note:
Preferences
Updated the preferences with a new one called
request_mobile_site
, which defaults tofalse
. There is also a menu item toggle under Tools called Request Mobile Site. The shortcut isCmdOrCtrl+Alt+U
, asM
was taken.U
for useragent? Not the clearest… Toggling this option updates the UA and reloads the site to reflect the change.UA Storage
We must store the mobile/desktop useragents. I couldn’t quickly find a way of requesting the default Electron UA. The webview must be mounted to the DOM before you can request it’s current UA. To get around this, I define the UA through
setAttribute
, as suggested here to avoid first load without the correct UA defined, effectively overwriting any requests for the current UA as a way of storing the default/desktop.Default (desktop) is what my current machine reads:
Mobile is an iPhone running iOS 11 in Safari:
This is probably fine for OSX releases, but we’ll want to find a better way of doing this if building for another OS.