search

QupZilla / qupzilla

Cross-platform Qt web browser
http://www.qupzilla.com
GNU General Public License v3.0
1.12k stars 348 forks source link

Allow Qupzilla to be Registered as Default Browser on OSX #2066

Open jonmchan opened 8 years ago

jonmchan commented 8 years ago

As far as I can tell, there is no ability to register Qupzila as a default browser in OSX. It would be great is Qupzilla can be registered as the default browser.

Martii commented 8 years ago

... no ability to register Qupzila as a default browser in OSX

There is ability just not implemented.

Here's a start for the assignee... add some variant of this somewhere around here in current /src/main/Info.plist

    <key>CFBundleURLTypes</key>
    <array>
      <dict>
        <key>CFBundleURLIconFile</key>
        <string>@ICON@</string>
        <key>CFBundleURLName</key>
        <string>http URL</string>
        <key>CFBundleURLSchemes</key>
        <array>
          <string>http</string>
        </array>
      </dict>
      <dict>
        <key>CFBundleURLIconFile</key>
        <string>@ICON@</string>
        <key>CFBundleURLName</key>
        <string>https URL</string>
        <key>CFBundleURLSchemes</key>
        <array>
          <string>https</string>
        </array>
      </dict>
    </array>

... this adds it to the registration for those schemes and shows up in System Preferences → General then Default web browser... however... on my OS X it's not loading the URL from the "webloc" files generated e.g. all it does it launch QupZilla to it's default start page. (is opening a 2nd start page tab though)

Martii commented 8 years ago

@nowrep So that "extra tab" that is being opened appears to be a missing command line feature in QupZilla with OS X. e.g. set browser default to QupZilla then...

$ open /Applications/QupZilla.app https://openuserjs.org

does not appear to work... however any other browser installed at that root application path does work e.g. set browser default to SeaMonkey then...

$ open /Applications/SeaMonkey.app https://openuserjs.org

So the above plist addition should be working but it uncovered something else which will prevent it from working I believe.

Also tried just a URL after open and it responds the same with QupZilla as default browser. So presumably if the parameter is sent to QupZilla then it could work.

Also just tried a thought...

$ open /Applications/QupZilla.app --args https://openuserjs.org

... and that did work with QupZilla as the default browser with the above plist code.

So somehow, in other browsers, they forward (or read in the existing parent args) the URL to the arguments of the application being opened.

nowrep commented 8 years ago

@Martii It probably creates QEvent::FileOpen that is handled in MainApplication (https://github.com/QupZilla/qupzilla/blob/master/src/lib/app/mainapplication.cpp#L1127), so maybe the problem is there?

Edit: Indeed looks like the issue is there, we should use QFileOpenEvent::url() instead of file().

Martii commented 8 years ago

Still not familiar enough with the available classes and the fromLocalFile appears to be file:/// related... (maybe both event tests?)

So unit tests should probably be:

Appreciate the looking into this... didn't realize until this issue that a basic feature wasn't available... with some assistance I can compile and test anything OS X if need be when available. Thanks.

nowrep commented 8 years ago

@Martii Can you please try now? I've committed the changes that should be enough to fix it.

Martii commented 8 years ago

Will do... not so sure if the plist is going to work condensed like that... thought of doing that myself but the <string>http URL</string> and above <string>https URL</string> difference might be enough to break proper registration or post other compatibility... will try it though.

Martii commented 8 years ago

Slight issue with registration... usually right after qmake is when QupZilla shows up in System Preferences Default browser list... however with condensed it doesn't show up until completely compiled.

webloc and html files work but...

$ open /Applications/QupZilla.app https://openuserjs.org

... opens up two instances of QupZilla and doesn't open the URL or a second tab at all now. Will try uncompressing the plist to see if that helps.

Martii commented 8 years ago

Uncompressed plist opens up OUJS... however still two instances of QupZilla... one has the Empty Page I start with and OUJS, and the other just has Empty Page that I start with.

So probably treating:

$ open /Applications/QupZilla.app https://openuserjs.org

as 

$ open /Applications/QupZilla.app
$ open https://openuserjs.org

... and other browsers are handling opening links in "new window" vs "new tab" is a strong guess.

Will recompile current HEAD one more time in case I made a user error but may need plist as described above... will edit if confirmed here... EDIT did appear to make a user error... slowed down this time to ensure a higher quality test.

Martii commented 8 years ago

Figured out where it shows that string for https URL btw... if you get RCDefaultApp-2.1.X.dmg (for viewing primarily as it hasn't been supported in a long time and some write ops don't seem to work) and check the System Preferences → Default Apps then goto URLs tab, then find http and https they both say they are pointing to label http URL... however default app is still QupZilla for both of them.

This may be fixed down the line with Apple so not sure what the long term repercussions of condensing the plist will be (besides QupZilla not showing until later after make instead of qmake in System Preferences, and the string misidentified which could possibly be read in by something else at a later date and could launch the wrong program assuming RCDefaultApp, or equivalent, worked for flipping just the http vs https.)... but appears to be working aside from the 2nd instance with $ open.

Thanks for your programming expertise @nowrep. :)

Re: above unit tests

Static HTML file sitting on desktop

  • PASS

    webloc file pointing to file:///

  • Opens up Safari and Finder, which is the default for OS X 10.11.6 (El Capitan) ... so missing that on the Apple side and is possibly their bug for the moment.

webloc file pointing to http://, etc.

  • PASS http
  • PASS https

Webpage html (URL with http and https)

  • PASS Open link in new window
  • PASS Open link in new tab
  • PASS Single primary click opens in current tab/window

Cross platform testing to make sure *nix and win still work since those "shortcuts" are in a different format (ini usually and not xml)

  • PASS $ qupzilla https://openuserjs.org/users/Marti (single instance launched)
  • PASS Static HTML file sitting on desktop (single instance launched)
  • PASS Symbolic link created in KDE/Plasma to file:/// URL (single instance launched)
  • PASS KDE/Plasma link to URL pointing to file:/// e.g. .desktop file (single instance launched)
  • PASS KDE/Plasma link to URL pointing to http:// e.g. another .desktop file (single instance launched)
  • PASS KDE/Plasma link to URL pointing to https://' e.g. yet another.desktop` file (single instance launched)
  • Windows is up to an available tester... should include a desktop shortcut series.
Martii commented 8 years ago

@nowrep

This didn't make it in for some reason... see 521d058...dd388cd (v2.0.1...v2.0.2) around Sept 4, 2016

Martii commented 8 years ago

@nowrep

There's a bunch missing I think esp. from September 2016 perhaps more.

nowrep commented 8 years ago

If you didn't commit it to v2.0 then it is only in master.

Martii commented 8 years ago

If you...

Owner of those commits are you not me.

commit it to v2.0

So you want everyone to checkout v2.0 branch first then add commits to that and push it upstream? My last commit is https://github.com/QupZilla/qupzilla/commit/18ab4f2a7b24d27becb5ed91fe952f8623741941 and that was committed with you (which that part of GH I've never figured out what that means and how to do it)... but that's against master with a new branch here.

Martii commented 8 years ago

e.g. https://github.com/QupZilla/qupzilla/compare/e906f6a...704933f are all missing from Version 2.0.2 and none of those are authored by myself directly. This is most likely every platform release not just OS X.

Martii commented 8 years ago

Additionally 399e0144e367cf2895cd0ce75254be21f152b2fa (SHA1) QupZilla-2.0.2.tar.xz is missing at the very least the issue commits of https://github.com/QupZilla/qupzilla/commit/d8354016563eafe6dc473969cbe1d10bc0043285 and https://github.com/QupZilla/qupzilla/commit/35657e60057c7a0337b55a62e414db9d801a2c30 . Presumably that whole range is missing from late August to September. :\

Confirmed missing from the tar ball (which is the same as git checkout tags/v2.0.2):

All confirmed not in the tar ball and of course the git checkout of that tag. (and also git checkout dd388cd of this repo's master). Something during that period is really foo'd I believe.

nowrep commented 8 years ago

That's fine, only bugfixes and selected commits should go to v2.0 branch. Everything else goes to master and will be part of next major release.

Martii commented 8 years ago

and will be part of next major release.

Hmmm so v3.x.x then... seems silly that registering a default browser and adding a language translation should be pushed that far ahead. Printing support as I've read is sort of incomplete at the moment so I can understand why it wouldn't be desired... as to the bringing back of a feature, that used to be in 1.8.9 presumably, not sure where that lays if it's a "new feature" considered by you or a true regression. shrugs

nowrep commented 8 years ago

2.1, and it will come soon. This should have been in 2.0.2, yet it was commited to master and wasn't backported to v2.0. I'm sorry about that, but since 2.1 will come soon it is not a big issue.

If you really want, you can manually backport those commits on top of official 2.0.2 release and send me the updated build.

Martii commented 8 years ago

It would be a start to move forward on this issue... I assume it would be nice to have a PR to set this inside QupZilla as well so those two commits are only approximately half of this issue but I have on occasion wanted to do this myself for testing OS level resources. Only critical thing I see is that Windows hasn't been tested yet... but if it's not in 2.0.2 then the non-compiler Windows users, like me, won't know for sure.

manually backport those commits on top of official 2.0.2 release

I can merge individual commits into a tree but I think rebase a commit to the tip is where this is typically done... still needs a tree branch made so I don't mess up my repo as well.

No need to apologize you know your structure better than I do... I'm just trying to understand a few things to be better able to bounce that information back when needed to the less informed... speaking of (me)...

Do you follow semver for releases? e.g. why I quoted you is that "major release" implies to me v3.x.x not a "minor release" of v2.1.x. You sort of answered this already but to be on the same page it helps to have a "mental filter" on when you say major it translates to minor.

Martii commented 7 years ago

@nowrep This can probably be closed now... been observing it and it's always there and it does open. Get's a little weird if I run QupZilla.app from the project tree with QupZilla ((undefined)) but once that is "trashed" it clears itself up.