dwb - a webkit web browser

portix · 2014-05-15 10:54:22

perdomainsettings does not work for all settings, it only works for builtin webkit settings and proxy is not builtin.

Edit: dwb uses the default proxy resolver of libsoup, it isn't possible to switch the proxy based on a domain with the default proxy resolver. I have started a branch where i implemented a proxy resolver that also supports pac-files, but haven't finished it. I don't remember how much work has to be done to finish it, if it isn't too much work i may finish it and merge it.

Last edited by portix (2014-05-15 10:59:40)

sekret · 2014-05-15 15:53:31

Oh ok, that explains it, thanks!

I don't know what a pac-file is, but this sounds really interesting. For now I'll switch it on and off manually, works as well, it's just not as handy and secure (automatic page reloads make the whole thing useless).

bstaletic · 2014-05-18 10:43:21

I'm having difficulties configuring a few things.
1. I want to set a keybinding for google search engine.
I did press "gs" on google.com and set it to "sg". But when I press sg nothing happens.
2. How do I copy and paste text (not using mouse)? Is there a caret mode for this? All yank options I saw deal with yanking either tab title or tab url.
3. How do I configure adblocking?
I installed the extension, and I tried binding the extension, but all ads are still there.

EDIT:
4. Can hits be nubers instead of letters? I don't see any pattern used for giving a link a hint.

Last edited by bstaletic (2014-05-18 10:47:26)

o_caino · 2014-05-18 10:51:18

bstaletic wrote:

1. I want to set a keybinding for google search engine.
I did press "gs" on google.com and set it to "sg". But when I press sg nothing happens.

When you press o to open an url, prepend "sg" to the word you want to search. e.g. "sg foo"

bstaletic · 2014-05-18 12:36:38

@o_caino
Thank you, that ofcourse worked.
Copy/paste and adblocking I managed to solve on my own.

Edit:
Figured out the hints also.

Last edited by bstaletic (2014-05-18 12:39:52)

gellex · 2014-05-19 17:23:10

Is there a way to force ssl? I found a script here but it doesn't work for e.g "youtube.tld" and also it's pretty time consuming to define every site.

bstaletic · 2014-05-19 17:39:01

@gellex
There's an option in dwb:settings with a discription "Whether to block http requests on https sites". It should work.

gellex · 2014-05-19 17:58:14

bstaletic wrote:

@gellex
There's an option in dwb:settings with a discription "Whether to block http requests on https sites". It should work.

I saw that I already checked that. Still no SSL on some sites despite they're secured in chromium
EDIT: I'm using HTTPS-Everywhere. That's the same I would like to have in dwb

Last edited by gellex (2014-05-19 17:59:49)

sekret · 2014-05-19 18:00:13

Example?

gellex · 2014-05-19 18:16:38

Well my fault. The chromium plugin seems to give misleading information. Thanks anyway

Trilby · 2014-05-22 18:35:22

Is it possible to set different behavior for opening a link vs downloading a link. The primary use case is links to PDFs. Sometimes I want to just view them without having to later delete the downloaded file, other times I actually want to save the pdf as a file.

I can get *either* of these behaviors. The first is by configuring the download-no-confirm, a download path, and using download manager in order to download to /tmp/ then view in mupdf. The second would be by (optionally) disabling the no confirm, but setting the download path to somewhere permanent (eg ~), and not using the download manager.

But when there is a pdf link on a page, I can right click, and in the webkit context menu there are options for "open link" and "download linked file". Ideally I'd like to set "open link" to download to /tmp/ and view the file in mupdf, but I'd like to keep "download linked file" able to download to a permanent location.

Is this possible?

EDIT: to clarify, currently the two context menu entries do behave slightly differently: download *only* downloads, open downloads and opens in mupdf (as I've configured). This is half way there, but they both download to the same location - this is what I'd like to be able to change.

Last edited by Trilby (2014-05-22 18:37:29)

Steef435 · 2014-05-22 19:57:48

You could use the contenthandler extension for that.

mimeType : {
    "application/pdf" : "do_something_with %u"
}

Last edited by Steef435 (2014-05-22 19:58:15)

Trilby · 2014-05-22 20:08:51

The content handler and the download handler do essentially the same thing. That is not the question. I'm curious how to have *different* actions depending on whether "open" or "download" is selected.

In other words, how would that "do_something_with" placeholder know whether the url was selected for download or for opening?

Last edited by Trilby (2014-05-22 20:09:39)

jpgg · 2014-05-22 21:28:42

Trilby wrote:

Is it possible to set different behavior for opening a link vs downloading a link. The primary use case is links to PDFs. Sometimes I want to just view them without having to later delete the downloaded file, other times I actually want to save the pdf as a file.

When I click on a pdf link, the path where to download is shown. If I hit Ctrl+x, I can instead choose an application with which to open the file (eg. mupdf) and the file is downloaded to /tmp and opened with mupdf. This is builtin; no configuration is needed. Moreover, dwb remembers that you opened a pdf with mupdf so that you don't have to specify it again. Is this a good solution for you?

Trilby · 2014-05-22 21:41:09

Thank you but no. I know how to get all that to happen. What I am looking for is (again) a way to have the two different behaviors in the same browser. Some pdfs I'd just like to view - others I'd like to download. There are two entries in the context menu, one for each of these - I'd like to get these menu entries to do different things with the pdf link.

With your set up, how do you then save a pdf you'd like to keep? After viewing it, you need to use another binding or command, or open a terminal, and copy the /tmp/name.pdf (or ~/.cache/dwm/name.pdf) to a different destination. This is what I'd like to avoid having to do every time I want to keep a pdf.

Last edited by Trilby (2014-05-22 21:42:45)

jpgg · 2014-05-22 22:01:17

Trilby wrote:

With your set up, how do you then save a pdf you'd like to keep? After viewing it, you need to use another binding or command, or open a terminal, and copy the /tmp/name.pdf (or ~/.cache/dwm/name.pdf) to a different destination. This is what I'd like to avoid having to do every time I want to keep a pdf.

I click on the link again and hit Ctrl+x again and Enter. This will download the file to the specified path. I don't think this is harder in terms of efforts than having to click on the link and select "Download file". Have you tried it?

jakob · 2014-05-22 22:24:25

Hm, why not just use the simple "click on the pdf" method to open it and the "right click select download pdf file"option to download the file? Or does it both have to be from the context menu?

Trilby · 2014-05-22 22:25:02

jpgg, none of that works with the no-confirm downloading - there is no opportunity to hit Ctrl-x.

@jakob, that's *exactly* what I'm looking for. But that doesn't work. The "download" option in the context menu will just do whatever the default method of opening it is. Normally I do just want to click (or keyboard "follow") on the pdf to view it - but I'd like the option to occasionally download one. If I'm set up to view pdfs when I click them, I no longer have the option of downloading them to a permanent spot. Right now, whenever I want to *keep* a pdf, I have to manually copy it from the temporary file that is dowloaded to a permanent location.

As a contrast (or example) in firefox/pentadactyl, I can click/keyboard-follow a pdf link and it will just show the pdf. But I can also (or alternatively) right click and "download" the pdf link if I actually want to keep the file. DWB can easily do the viewing part the same, but then even though there is a context menu option to download, I've lost the option to actually save the file somewhere meaningful.

Last edited by Trilby (2014-05-22 22:35:28)

Steef435 · 2014-05-23 18:10:29

Trilby wrote:

The content handler and the download handler do essentially the same thing. That is not the question. I'm curious how to have *different* actions depending on whether "open" or "download" is selected.
In other words, how would that "do_something_with" placeholder know whether the url was selected for download or for opening?

When I left-click(or "open link") on a pdf link I get the contenthandler handler(download to /tmp and open), and if I choose "download" I get the standard download procedure. I'll update to the newest git build tonight to see if it changes anything for me.

I don't use downloadmanager.

In the contentmanager settings I showed earlier I call a script containing something like this($1 being the url):

wget -P "/tmp/pdf/" "$1"; zathura "/tmp/pdf/`basename \"$1\"`"

What do you have in your contentmanager and downloadmanager config files regarding this issue? Do you use dwb from the repos or a recent git snapshot?

EDIT: The script seems to be called when I click on the link, use the "open link" context menu option or follow the hint in a new tab(F), not in the current tab(f).

Last edited by Steef435 (2014-05-23 18:13:13)

Trilby · 2014-05-23 19:54:11

I don't (currently) use the content manager, only the download manager. As I understood it, only the latter could work with the download-no-confirm setting, but I'll try to mimic your set up momentarily. For the other question, I'm using dwb-git.

EDIT: Thanks, that works perfectly now. I've disabled the download handler, re-enabled the content handler, and moved the multiple commands into a script (content handler rules couldn't execute both the wget and mupdf commands - I suspect they use a call to an exec family function rather than running it in a shell). I've now set the download directory in dwb:settings to be my home folder, and use the script to wget to /tmp/dwb.pdf and view /tmp/dwb.pdf. This produces exactly the results I was after.

Last edited by Trilby (2014-05-23 20:09:59)

portix · 2014-05-23 21:38:04

@Tribly: dwb doesn't check what those default menu entries do. If a link cannot be opened by webkit "Open Link" and "Download linked file" will do exactly the same. If you want context menu entries where you can choose between downloading and opening the file you can add menuentries yourself. Here is a quick example script, not well tested and very hackish, it also only offers to open it with a pdf-viewer, it doesn't guess which filetype the download will have:

//!javascript

var pdfCommand = 'sh -c "mupdf \'%f\'"';
var wgetCommand = 'sh -c "wget \'%u\' -O \'%f\'"';

// either downloadWebkit or downloadWget
var downloadAction = downloadWebkit;

var downloadDirectory = settings.downloadDirectory + "/";
var cacheDir = "/tmp/";

var contextUri;

var menuItems = [ { 
    label : "_Download to " + downloadDirectory, 
    callback : download
}, {
    label : "_Open with pdfviewer",
    callback : open
} ];

function getDestinationName() {
    var destination = contextUri;
    var lastSlash = contextUri.lastIndexOf("/");
    if (lastSlash >= 0) {
        destination = contextUri.substring(lastSlash + 1);
    }
    var additionalQuery = destination.search(/[&?]/);
    if (additionalQuery > 0) {
        destination = destination.substring(0, additionalQuery);
    }
    return destination;
}

function downloadWebkit(dir, onFinished) {
    var download = new WebKitDownload(contextUri);

    var downloadPath = dir + download.suggestedFilename;
    download.destinationUri = "file://" + downloadPath;

    download.start(function() {
        if (onFinished && download.status == DownloadStatus.finished) {
            onFinished(downloadPath);
        }
    });
}

function downloadWget(dir, onFinished) {
    var destination = dir + getDestinationName();
    return system.spawn(wgetCommand.replace("%u", contextUri).replace("%f", destination)).then(
        function() {
            if (onFinished) {
                onFinished(destination);
            }
        }
    );
}

function download() {
    downloadAction(downloadDirectory, function() {
        io.notify("Download complete");
    });

}

function open() {
    downloadAction(cacheDir, function(file) {
        system.spawn(pdfCommand.replace("%f", file));
    });
}

function onContextMenu(w, menu) {
    menu.addItems(menuItems);
}

Signal.connect("buttonPress", function(w, result, e) {
    if (e.button == 3 && result.context & 2) {
        contextUri = result.linkUri;
        Signal.once("contextMenu", onContextMenu);
    }

});

Trilby · 2014-05-23 21:44:13

Thanks Portix - that's awesome to know how to add context menu entries - but Steef's suggestion above is perfect. I didn't actually need the context menu options to both work - I just need a way to get each behavior. I like Steef's suggestion which allows viewing a temporarily saved file as the default for click/follow as long as the "download" option in the context menu still provides the opportunity to save the file - which it now does.

cju · 2014-05-24 19:03:23

Uuuhhhhhh… Using the latest git version of dwb along with the closed nvidia driver, flash videos are blue where they should be red.

Yeah, I know that this is quite a known flash + nvidia problem that reappears every now and then, BUT here it ONLY happens with dwb, NOT with firefox, so changing the global flash settings might not be a good idea, I guess.

Trilby · 2014-05-24 20:32:36

cju, this may be relevant.

cju · 2014-05-25 08:33:15

Trilby wrote:

cju, this may be relevant.

Thanks, I already knew that trick with disabling the hw-acceleration, that's why I asked again if this is the only solution since the change of flash settings also affects flash in firefox, and that's not what I want. Also, flash becomes quiet unstable...

Arch Linux

#2101 2014-05-15 10:54:22

Re: dwb - a webkit web browser

#2102 2014-05-15 15:53:31

Re: dwb - a webkit web browser

#2103 2014-05-18 10:43:21

Re: dwb - a webkit web browser

#2104 2014-05-18 10:51:18

Re: dwb - a webkit web browser

#2105 2014-05-18 12:36:38

Re: dwb - a webkit web browser

#2106 2014-05-19 17:23:10

Re: dwb - a webkit web browser

#2107 2014-05-19 17:39:01

Re: dwb - a webkit web browser

#2108 2014-05-19 17:58:14

Re: dwb - a webkit web browser

#2109 2014-05-19 18:00:13

Re: dwb - a webkit web browser

#2110 2014-05-19 18:16:38

Re: dwb - a webkit web browser

#2111 2014-05-22 18:35:22

Re: dwb - a webkit web browser

#2112 2014-05-22 19:57:48

Re: dwb - a webkit web browser

#2113 2014-05-22 20:08:51

Re: dwb - a webkit web browser

#2114 2014-05-22 21:28:42

Re: dwb - a webkit web browser

#2115 2014-05-22 21:41:09

Re: dwb - a webkit web browser

#2116 2014-05-22 22:01:17

Re: dwb - a webkit web browser

#2117 2014-05-22 22:24:25

Re: dwb - a webkit web browser

#2118 2014-05-22 22:25:02

Re: dwb - a webkit web browser

#2119 2014-05-23 18:10:29

Re: dwb - a webkit web browser

#2120 2014-05-23 19:54:11

Re: dwb - a webkit web browser

#2121 2014-05-23 21:38:04

Re: dwb - a webkit web browser

#2122 2014-05-23 21:44:13

Re: dwb - a webkit web browser

#2123 2014-05-24 19:03:23

Re: dwb - a webkit web browser

#2124 2014-05-24 20:32:36

Re: dwb - a webkit web browser

#2125 2014-05-25 08:33:15

Re: dwb - a webkit web browser

Board footer