View Single Post
jukey's Avatar
Posts: 246 | Thanked: 204 times | Joined on Jun 2007 @ Potsdam (Germany)
#157
Originally Posted by steven676 View Post
Thanks for the report -- I've committed a fix, which will be in the next release.

I'm unclear as to whether it'd be best to push a release with this fix into extras-testing now (and reset the 10-day clock, as I understand it) or wait until the package reaches extras before pushing a quick fix release. (I don't anticipate 3.4 will come particularly soon, and it seems silly to hold a one-line, low-risk fix that long.) Opinions?
I prefer the option to push the new version now and to reset the timer again. There was never a version of browser-switchboard in extras until today so it should not be a problem to wait 10 days longer.
I also will advertise the package a little bit at the Testingsquad mailing list to make sure there are at least 10 votes which are needed to unlock the package for promotion after 10 days.

Also, applications are supposed to have a way to request that a link load in an existing browser window (the load_url method). Currently, we treat this the same way as a request to open a new window. I question whether it's appropriate for applications to be allowed to choose the behavior, but strictly, if we're to have bug-for-bug compatibility with MicroB, we should implement this where possible. Comments?
I would prefer that
  • the default setting ist "open in a new window" (this ist the current behaviour)
  • there is a check box to configure that in the settings dialogue (maybe in a future version of browser-switchboard)

However I don't know a use case where it would be great to have a new link opened always in the same window. If the "first" application wish to do that an implementation could be considered.

Best regards, Uwe
__________________
-> Join the SailfishOS Meetup Berlin - every first Monday a month <-

Me on twitter
 

The Following User Says Thank You to jukey For This Useful Post: