Search results for "plugin" - Dillo-dev

Re: [Dillo-dev] [RFC] Plans for next version of tab patch

by Jorge Arellano Cid

Hi Frank, On Tue, 17 Jun 2003, Frank de Lange wrote: > Hej! > > Now that the first release of my tab patch is 'out there', I'd like to > give a short overview of my plans for the next version of this patch. If geocities stops working just let me know, or ask Andreas who mirrored the patch... > I > do not know when I'll be able to release this next version, as I'm busy > this week, followed by a trip to the UK (back the 13th of juli), but I > will try to make it relatively soon... No problem. Some time ago (maybe a lot), Arvind told me he had developed a "tabs" patch for dillo: http://www.dillo.org/test/dillo_tabs.png He had to work on it some more, then he got very busy, and I haven't heard of it in a long time... Technically, what interests me more about the patch is the separation of interface code out of document code. Now Sebastian is working on another separation; for CSS (it also involves several files), so I think it is better to keep both works separated until our re-structuring of the parser is well defined. I'd advise you to choose a date from CVS and improve the patch against it (not trying to catch up with current); that way the patch can be polished without too much hassle and with the feedback of interested developers. Then, when the time to merge comes, it will be stable, clean and polished. Personally, I can't look at it right now (because of the above mentioned reasons, plus I'm dedicated to the dillo plugins extensions). NOTE: We have advanced a lot with Ferdi on dpid, so it will soon be integrated and commited. ... it has come a tradition (or better, our way of development) to test a lot the patches before commiting them in. That way, the CVS keeps stable, the code clean, and we can keep up with the ideal of always releasing a better Dillo than the former. As you noticed, the patch generated a lot of feedback. I hope patches start to come just as bug notes! ;) > [...] > > Jorge, let me know if/when you plan to commit the patch to CVS (read above) Last, but not the least, I also think that tabbing is a function that should/must be done by the WM. I always try to find "the right place" to put a patch, and IMO it belongs to the WM. Now, as these days only a few WMs come with good tabs support, and as the patch seems small, it should pose no major trouble to eventually commit it. Welcome aboard! Jorge.-

21 years, 4 months

Re: [SCRIPT] Run Dillo with a random user agent

by Rodrigo Arias

Hi Alex, On Tue, Jul 09, 2024 at 12:31:29PM +0200, a1ex(a)dismail.de wrote: >On Mon, 8 Jul 2024 14:50:08 +0200 ><a1ex(a)dismail.de> wrote: > >> Hi list, >> >> Here is a simple script which runs Dillo with a random user agent on >> each run. I've been using it for a long time with no issues. It would >> be interesting to have similar functionality built-in to Dillo at some >> point, at least for me. >> >> ... Thanks!, I think is a good idea to reduce fingerprinting in Dillo. Have you considered also removing the user agent header completely? I work under the assumption that each Dillo user is uniquely identifiable based on non-JS enabled, other HTTP headers, TLS behavior, TCP and network timing leaked details, unless I have evidence that suggests otherwise. I don't think the web is designed to keep users anonymous and there is only so much we can do. However, I would appreciate efforts towards reducing the fingerprinting information we are leaking. It would be nice to be able to measure it somehow, but I only find JS enabled fingerprinting estimation tests online. >Just to add to this, have you considered the idea of a user agent >switcher in Dillo? It would be neat to be able to choose from different >profiles and have them applied in real-time without having to restart >the browser. For example, the profiles could be something like: > >'Default', 'Desktop', 'Mobile', 'Random' I thought about something like this but for the CSS media selector, not so much for the user agent. I'm not sure if switching the user agent among desktop/mobile would have a measurable effect on the page content. If you want to reduce information leaked by Dillo that can identify a user, I think a good strategy is first to make a service that can measure this information among Dillo users and show the differences it can find among users, much like the EFF does[1]. Maybe we can work with the EFF to improve the support for non-JS browsers, so we can benefit from their pool of users to estimate uniqueness. [1]: https://coveryourtracks.eff.org/ We can also make it cooperate with a Dillo plugin that can have access to network TCP packets and timing information on both ends to emulate an state actor, so we can estimate how much information is being leaked and how much we are reducing it. This is probably something that we may want to bring up to the Tor team to see which strategies the did for the Tor Browser and which ones we can apply to Dillo. See also: https://github.com/dillo-browser/dillo/issues/135 Best, Rodrigo.

4 months

Re: [Dillo-dev]https (eg for posting to ps2 bulletin boards)

by Madis Janson

On Tue, 1 Jun 2004, Jorge Arellano Cid wrote: > The current prototype for SSL (using dpi) provides for an easy > way of implementing connection caching, and for asking the user > (using dillo's API) whether to continue on unverified > connections, the SSL part of this verification is not yet done > though. > > As Madis put it: > > > Most important thing missing from the ssl specific code is certificate > > verification - it MUST be done in order to have any actual security. > > In its current form it just gives a way to access SSL sites, but not > > secure access. > > I know people look forward to the day when they can complete > their online shopping with dillo, but we must be very careful to > provide real security. This is key. I hope to look at it (probably in july). > Unfortunately I'm not an encryption expert, and we need some > help from a savvy guy (the chances of a SSL freshman to make > mistakes is very high). Yes, it is a hard thing. There were for example a same SSL certification chain handling bug in IE and Konqueror. It would help, when someone would write a library-like code for verifing peers certificate with simple interface. I'd look the existing implementations in Konqueror SSL plugin and Mozilla for reference. For example something similar to this: /** * Check the peer's certificate. * * \param connection current SSL connection * \param result the verifications result * 0 - ok * 1 - we don't know wtf it is, ask confirmation * and tell user, that good answer is NO. * 2 - error, couldn't do the verification * .... * \return message for user */ char* chain_verify(SSL *connection, int *result); /** * User said, that he likes that one... * * \param cert certificate to remember * \return 0 - error (message in openssl error stack), 1 - OK */ int remember_certificate(X509 *cert); > I'd love to have a TLS based dpi for https (TLS lib is GPLed > and is a requisite to NPTL, so it'll become as ubiquitous as SSL > lib). The current prototype is SSLlib based, but is enough to > start polishing and extending the code. > > Some time ago Madis wrote an SSL gateway for Dillo. After some > work, I decided to integrate it through the dpi framework (to > empower it with dpip and also to avoid some quirks by using the > standard way to extend dillo). That is the current prototype. http://www.zone.ee/myzz/dillo/https_dpi/https_dpi.tar.gz But if someone knowledgeable of crypto, SSL and TLS library goes to write the TLS version of it, do it (and tell the list). I do not know the TLS library by myself.

20 years, 5 months

non released unfinished code (try 2)

by Diego Sáenz

It seems that my previous mail came bad, so i try again: Hello. I agree (in the general discussion) that it is a bad idea to keep closed the dillo FLTK code. (I reserve other opinions for other mail) This mail is only because i have some unfinished code for dillo and want to open/show/give to the rest of the list. One can not demand something without do the same. I have a Dillo PlugIn that add tabs to dillo. The plug in is a GTK 1.2 app and a DPI at the same time. I do not known GTK 1.2 and do not have time to learn it. I was waiting for the FLTK dillo to program a FLTK version, but now i think that it is better to show bad programed unfinished code instead of wait. Try to run it before watch the code (based on a GTK 1.2 example) I hope that some GTK programer can finish it. How do it work: Now dillo can be embedded in other program. This is used by sylpheed for example. The app create a especial gtk widget get its xid and run dillo like that: $ dillo -x xid(this is a number) Then that dillo will appear in the gkt widget and not in a separate window. With a few changes (18 lines added to dillo) dillo can ask the xid to a DPI when it want to open a new window. The DPI is a GTK window with a notebook widget. Each time dillo ask it for a xid the DPI adds a new tab and pass its xid to dillo and dillo appear in the tab. (If the xid returned by the DPI is 0 dillo open a separate window) TODO: - Remove the GTK example code - Add menus to tabs, close tab button ... - maybe add a configuration file Instructions to test it: download the patch attached to this mail (tabs_dpi.diff) get the last dillo cvs (if asked for a password, press ENTER) $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo login $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dillo change to the dillo cvs directory and apply the patch $ cd dillo $ patch -p1 < ../tabs_dpi.diff generate configure, configure code and compile it $ ./autogen.sh && ./configure --disable-dlgui && make install the tabs dpi and optionaly the patched dillo # make install run the patched dillo comanding it to ask the xid and with a given size (only to see the dillo window entirely) $ dillo -x ask -g 700x500 To open a new tab use midle click on a link or the menu file->new browser To close a tab use the remove page button or the menu file->close window Excuse me my english and please test and tell what you think about this. Diego.

17 years, 7 months

Re: patch: python filter DPI supporting the "data:" scheme from RFC 2397

by Ben Wiley Sittler

This updated copy of the patch corrects Content-Type defaulting (text/plain;charset=US-ASCII if empty, text/plain if empty but charset given.) This appears to work with all the Mozilla data: URL test-cases except the JavaScript, CSS, XUL and MP3 ones (the MP3 one deserves further investigation.) See: http://www.mozilla.org/quality/networking/testing/datatests.html On 12/5/05, Ben Wiley Sittler <bsittler(a)gmail.com> wrote: > Hi! I've been using dillo a bit since the i18n patch became usable, > and found that there was one crucial URI scheme missing: "data:", > defined in RFC 2397. I used the simple filter DPI model and had > something working fairly quickly (thank you all for making that easy!) > > This works by adding a filter for dpi:/dataurl/... and rewriting > data:... to use it, in a fashion similar to the one used by the https > filter. > > The data: URI scheme allows image data (and other linked resources) to > be embedded in a web page, so (for example) your DPIs can now > trivially embed images, even dynamically-generated ones. It is also > supported by the Mozilla family (it's used heavily in GreaseMonkey > plugins) and in Konqueror and Safari. > > Here's an example data: URI (an image) from the RFC: > > <IMG > SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw > AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz > ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp > a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl > ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis > F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH > hhx4dbgYKAAA7" > ALT="Larry"> > > The ";base64" is optional, and indicates Base-64 encoded data. The > default is unencoded, i.e. just URL-escaped. Here's a non-Base-64 > conversion of the same data: > > <img > src="data:image/gif,GIF87a0%000%00%F0%00%00%00%00%00%FF%FF%FF%2C%00 > %00%00%000%000%00%00%02%F0%8C%8F%A9%CB%ED%DF%00%9C%0EH%8Bs%B0%B4%AB > %0C%86%1E%14%96%A64.%E7%2A%A6%09%8B%1A%A7%2B%AFQIo8%D9%8Ef%D7%F3%80 > %5C%C1%C90u%D1%0819%1D%13%A8%14%1E%8E%14M%CC%E7%E4T%9F%B9b%25%2A%AD > qyc%99J%87%F0%DE%B8%D7%0F%E7%22%D6%1A%C1%1B%B4%B8%8EJ%96%BFL%F8%3B% > 26%92G%C7%27%A7w5%93%05%F5%F4s%13%A7%28%F8%E0%078%B8v%28%A7Xgd%17%C > 9%23u%F9%F2q%06We%E6%06z9%89%95%97%86%97%D8%B6%89%C5jh%D5Z%8AT%FA%1 > 7%98%89%F7I%BA%9A%FB%93K%83%8A%D3%934%BC94C%85%D4%B7%0B%CA%3B%3A%DC > wx%AA%F6%E8%AC%17%CDL%D4%E2%1CG%B9D%7B%0C%1C.%9E%ED%B8%D3d3%7B%8D%9 > D%AD%C5%D8%94%05%A3%DE%D5%AE%2C%BF%5E%5E%3F%7FW%1F%E5U%B3_%2C%A6%EC > %F1%E1%87%1E%1Dn%06%0A%00%00%3B" > alt="Larry" > /> > > So far this DPI has only been tested with the i18n-patched version of > dillo (I use it to load small test texts in different charsets), but > it should theoretically work in regular dillo too. > > Enjoy, > -ben > >

18 years, 11 months

Re: [Dillo-dev] dillo-0.8.6-pre(CVS) compile error

by Diego Sáenz

El Sun, 4 Sep 2005 02:01:04 -0700 south park <llmmix(a)gmail.com> escribio: > Hi, > It works if compiled without "--disable-cookies" option. > how to disable cookies in dillo? Dillo disables cookies by default (cookies are configured with the $HOME/.dillo/cookiesrc file), but the code to use cookies is in dillo(in that version in a DilloPlugIn outside dillo, but exec by dillo if cookies enabled) is there. Read doc/Cookies.txt in dillo sources for more information. (the answer continues down) > > XXX@debian:~/download$ cd dillo > XXX@debian:~/download/dillo$ ./configure --disable-cookies > ... > XXX@debian:~/download/dillo$ make > make all-recursive > make[1]: Entering directory `/home/XXX/download/dillo' > Making all in doc > make[2]: Entering directory `/home/XXX/download/dillo/doc' > make[2]: Nothing to be done for `all'. > make[2]: Leaving directory `/home/XXX/download/dillo/doc' > Making all in src > make[2]: Entering directory `/home/XXX/download/dillo/src' > Making all in IO > make[3]: Entering directory `/home/XXX/download/dillo/src/IO' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory `/home/XXX/download/dillo/src/IO' > make[3]: Entering directory `/home/XXX/download/dillo/src' > make[3]: Nothing to be done for `all-am'. > make[3]: Leaving directory `/home/XXX/download/dillo/src' > make[2]: Leaving directory `/home/XXX/download/dillo/src' > Making all in dpid > make[2]: Entering directory `/home/XXX/download/dillo/dpid' > make[2]: Nothing to be done for `all'. > make[2]: Leaving directory `/home/XXX/download/dillo/dpid' > Making all in dpi > make[2]: Entering directory `/home/XXX/download/dillo/dpi' > gcc -I/usr/include/glib-1.2 -I/usr/lib/glib/include -g -O2 > -DDISABLE_COOKIES -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return > -L/usr/local/lib -o cookies.dpi cookies.o dpiutil.o -L/usr/lib -lglib > /usr/lib/crt1.o: In function `_start': > ../sysdeps/i386/elf/start.S:115: undefined reference to `main' > collect2: ld returned 1 exit status > make[2]: *** [cookies.dpi] Error 1 > make[2]: Leaving directory `/home/XXX/download/dillo/dpi' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/XXX/download/dillo' > make: *** [all-recursive-am] Error 2 > XXX@debian:~/download/dillo$ > Is something that knows about Makefiles and auto* tools interesting in helpme to fix this? I do not have the knows for it. I think that the cookies.dpi must not be compiled if cookies are disabled with "./configure --disable-cookies". More about makefiles: Can somebody write a generic makefile for DPIs(DilloPlugins) distributed outside dillo source. It need to install the compiled DPI(DilloPlugIn) in the DPIs system directory when "make install" run as root or install the DPI in the $HOME/.dillo/dpi/ when not and then exec "dpidc register" I think a version of the hello plugin distributed outside dillo can help to the people to write more DPIs. Diego.

19 years, 2 months

Re: [Dillo-dev]https (eg for posting to ps2 bulletin boards)

by Jorge Arellano Cid

On Sun, 30 May 2004, robert w hall wrote: > Every time I read the playstation2-linux lists I realise how very useful > dillo will be when it gets just a little further. Please elaborate a bit on this subject. > How's the short/medium term future of https looking?(*) > If an official plugin is in the offing then that's probably what we > should all wait for. The short term looks very good, at this time we only need some TLS or SSLlib savvy guys, with some time willing to polish our current prototype. The main problem with the past prototypes and patches is that they don't handle connection caching (nor provided for an easy way to implement that), and the most important, they don't do certificate validation! The current prototype for SSL (using dpi) provides for an easy way of implementing connection caching, and for asking the user (using dillo's API) whether to continue on unverified connections, the SSL part of this verification is not yet done though. As Madis put it: > Most important thing missing from the ssl specific code is certificate > verification - it MUST be done in order to have any actual security. > In its current form it just gives a way to access SSL sites, but not > secure access. I know people look forward to the day when they can complete their online shopping with dillo, but we must be very careful to provide real security. This is key. Unfortunately I'm not an encryption expert, and we need some help from a savvy guy (the chances of a SSL freshman to make mistakes is very high). I'd love to have a TLS based dpi for https (TLS lib is GPLed and is a requisite to NPTL, so it'll become as ubiquitous as SSL lib). The current prototype is SSLlib based, but is enough to start polishing and extending the code. Some time ago Madis wrote an SSL gateway for Dillo. After some work, I decided to integrate it through the dpi framework (to empower it with dpip and also to avoid some quirks by using the standard way to extend dillo). That is the current prototype. Just in case an SSL/TLS savvy person is reading: the work with the dpi is quite simple, you don't need to know about Dillo's internal working, actually the https dpi is a C program that's independent of Dillo. The dpi just needs to make the secure connection to the remote server (and verify the cerificate), then forward the http stream to dillo, or ask whether to close or proceed when it can't verify. This is done with a simple dpid tag, all the SSL stuff happens inside the dpi. > Otherwise, is the patch from 0.7 resurrectable?? Sure, but not worth. At least the current prototype can POST. Cheers Jorge.-

20 years, 5 months

Re: [Dillo-dev] How to get dillo up to speed; was: LinuxBIOS with X Server Inside

by Alan Carvalho de Assis

Hi Jorge, 2007/3/31, Jorge Arellano Cid <jcid(a)dillo.org>: > > Guys, please allow me to say that these comments hurt... > > > I do sincerely appreciate the interest that you show in Dillo; > to me it means you understand the concept of it and have hopes in > the project evolving to its vision. > > Me too. I dedicated seven years of my life to developing Dillo > full time. Living on donations, in poor neighborhoods, rejecting > high salaries, and trying to explain my (non-technical) family I > was not crazy for doing it. All this time the code has been open > and GPLd. Anyone could have done the same I did for the project. > > Sebastian made a huge effort too. Having a job and developing a > web browser is a very demanding task, and he did even more than > that. I highly respect the man. > > In Germany we decided with him to keep the Dillo FLTK2 closed > until we both agreed to release. This was mainly because a > company was to hire us to develop it and declined on the last > minute. > > I once asked in this list how many developers were willing to > work on Dillo FLTK2 if released. One answer still stands. > > From some time ago I think it would be good to release the new > code. I have emailed several times with no answer. > > Finally, I currently fail to see I'm the problem, but it could > be. No person saying otherwise is a strong sign. > I appreciate your dedication to Dillo, you was (are) a good father to this project. As all father you want to protect your child and have fear the way it can follow. But Dillo need to evolve to support features only existents in modern browsers as i18n, javascript, https, tabs, flash (gnash), etc. I know you always had fear that Dillo become very fat and run away from the original intention of project. But maybe you can found a way to balance between these 2 variables (features / size and/or speed), maybe a modular system (using the Dillo plugin system for example). Keeping the source code closed you will not get developers and day after day this code base will become deprecated and don't will get new features. This is the evolution theory of Darwin, if it don't evolve it will die and will be replaced by other (Minimo?, NetSurf?, other). Please Jorge think about this. Now that Linux is become the mainstream on smart phone market, Dillo can get a break (get a chance), but keeping it closed source (on closed curtains) will be more difficult to company see the Dillo potential. > > -- > Sincerely > Jorge.- > Best regards, Alan

17 years, 7 months

dillo-2.1.tar.bz2

by devidfil＠gmail.com

On Thu, Jun 18, 2009 at 6:57 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: > Hi, > > ?Working on: > > ? ? 1.- Solve the OpenSSL license issue and upload rc3. > > > On Thu, Jun 18, 2009 at 05:24:25PM +0200, Devid Antonio Filoni wrote: >> On Wed, Jun 17, 2009 at 11:45 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: >> > On Wed, Jun 17, 2009 at 10:01:12PM +0200, Devid Antonio Filoni wrote: >> > [...] >> > ?Devid: please send me the .deb and its directions when done. >> DONE! You can find it at https://launchpad.net/~d.filoni/+archive/ppa >> . However I found an error checking my package using lintian: >> >> E: dillo: possible-gpl-code-linked-with-openssl >> N: >> N: ? ?This package appears to be covered by the GNU GPL but depends on the >> N: ? ?OpenSSL libssl package and does not mention a license exemption or >> N: ? ?exception for OpenSSL in its copyright file. The GPL (including version >> N: ? ?3) is incompatible with some terms of the OpenSSL license, and therefore >> N: ? ?Debian does not allow GPL-licensed code linked with OpenSSL libraries >> N: ? ?unless there is a license exception explicitly permitting this. >> N: >> N: ? ?If only the Debian packaging, or some other part of the package not >> N: ? ?linked with OpenSSL, is covered by the GNU GPL, please add a lintian >> N: ? ?override for this tag. Lintian currently has no good way of >> N: ? ?distinguishing between that case and problematic packages. >> N: >> N: ? ?Severity: serious, Certainty: wild-guess >> >> Can you please fix it? > > ?AFAIS, the only program that links to OpenSSL is the https dpi. > i.e. The ssl-enabled dillo binary doesn't link to it. > ? ? https.filter.dpi links to it. > > ?IANAL, but it looks like giving permission for this dpi is enough, > and it's already done in its sources (dpi/https.c): > > ?* [...] > ?* As a special exception permission is granted to link the code of > ?* the https dillo plugin with the OpenSSL project's "OpenSSL" > ?* library, and distribute the linked executables, without including > ?* the source code for OpenSSL in the source distribution. You must > ?* obey the GNU General Public License, version 3, in all respects > ?* for all of the code used other than "OpenSSL". > ?* > ?*/ > > > ?Please let me know if this is _really_ enough or if some extra > legal formula must be added somewhere else. It should be enough, at least this is what I see for example at http://lists.octality.com/pipermail/cherokee/2008-November/009408.html (take a look in that page for more infos) > ?TIA. > > -- > ?Cheers > ?Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > Devid

15 years, 4 months

dillo 2.1

by sandshrew＠gmail.com

On Mon, Jun 22, 2009 at 06:49:06PM +0200, Johannes Hofmann wrote: > Hi Tomas, > > On Mon, Jun 22, 2009 at 05:12:07PM +0300, Tomas R wrote: > > Been testing dillo 2.1 for some time and would like to share my > > experience. > > > > It's really great to see some basic css support (appearance of most if > > not all websites has improved alot), properly resized images, > > redirection and basic authentication working now :) > > > > Anyway, even dillo improved alot recently there still seems to be some > > issues. Here are some I've noticed after testing this release for few > > days: > > Rendering > > 1) ubuntu.lt > > Not sure if it's dillo fault or website's malformed stylesheet, but > > with default dillo settings some of the lithuanian characters are not > > displayed. This can be fixed by just adding "* {font-family: > > serif !important}" to the style.css. Here is a pic with some of the > > places where letters are missing marked in red: > > http://img4.imageshack.us/img4/2227/ubuntult.png > > I guess the problem is that the font simply does not contain those > glyphs. There are some rules how this case should be handled, but > dillo does not implement them currently. > I see. > > 2) gmail > > It's nice that login works now, but with default dillo settings the > > size of most of the text is 1px. This can be partially fixed by adding > > font_min_size to dillorc, but it's obviously a dillo bug as this > > doesn't happen with links-hacked. > > I don't have a gmail account, so I can't reproduce it, but > there seems to be a general bug in the CSS code that makes fonts > smaller than in other browsers. The account is just few clicks away ;) > > 3) google > > What's with the textarea in the top left corner of the page? And just > > for information: signing out doesn't work because it requires basic > > javascript support (works with links-hacked). > > That textarea is in the google page. It's just hidden due to a > "display: none" CSS directive which is not supported yet by dillo. > Actually I'd like to know the reason why it is there before > hiding it. > I guess, that's a honeypot for spambots. > > 4) Black on black, white on white... > > http://www.nma-fallout.com/forum/viewtopic.php?t=42776&start=2660&sid=a5712… > > For some reason black font color is used here and we get black text on > > black background in some posts (doesn't happen with links-hacked). > > Oh. This is just horrible HTML / CSS, it's full of bugs! > The reason for black on black is: > <body bgcolor="#000000" text="#C0C0C0" link="#33CC00" vlink="#33CC00" /> > > I.e. body is immediately closed. But there is tons of other bugs on > this page. I see. I'll try to contact the admin and see if I can fix some of the bugs. > > http://www.acetoneteam.org/ > > Background color is not set here and if we have "body > > {background-color: white}" rule in our style.css file, we get white > > text on white background. > > dillo does not handle color definitions of the form rgb(255,255,255) > yet. I guess we can fix that. > Sounds good :) > > 5) http://ubuntuforums.org/showthread.php?p=6592005 > > What's with the PINK blocks? If that's more of a "feature" then a bug, > > can the color be changed by using some css rule? > > I can't find pink blocks on that page. Where exactly do you see > them? Maybe post a screenshot. > Sure. Some of the blocks marked in red: http://img20.imageshack.us/img20/2749/ubuntuforums.png http://img20.imageshack.us/img20/6066/ubuntuforums1.png > > 6) http://www.binaryworld.skynet.lt/DUK.html > > If we use one link with fragment identifier in the page, all the others > > are marked as visited too. > > Not sure how this should be handled correctly. Someone will have to > check the specs. > I've checked opera, firefox, midori and chromium (aka google chrome under BSD license) browsers. None of them act like that. > > 7) Authentication > > Basic authentication does work now, but at first the server displays a > > message saying "wrong credentials or browser doesn't > > understand how to supply the credentials" and only then a window > > pops up asking for the credentials... > > > > UI > > 1) Positioning the tab close button on the top RIGHT corner of the > > browser isn't a good thing because: > > a) The distance between the most commonly used buttons and the tab > > close button is pretty big (especially when widescreen monitors are > > pretty common nowadays); > > b) It only allows closing the active tab; > > I think it would be much better if all tabs had close buttons or at > > least the button was placed near the last tab. > > Agreed. Patch welcome :) > > > 2) Trivial but... because the setting to enable/disable image loading > > now is in the wrench menu it is two clicks away instead of one as it > > used to be in dillo 2.0. Maybe css settings could be left where they are > > now, but the setting for enabling/disabling images could be moved where > > it was in dillo 2.0? > > 3) UPPERCASE letters should be used in the File menu to define keyboard > > shortcuts, because now L looks like I (Open url... ctrl+l) > > 4) Don't you think "Are you sure you want to close the browser?" > > message is pretty annoying? > > Which one exactly? When exiting dillo with multiple tabs/windows > open? > I don't think dillo asks a lot for confirmation, but I normally use > multiple Ctrl-q's to close all tabs and windows and quit. > Yup, the one with multiple tabs. I just use my WM's shortcut for closing the window. > > > > Other: > > It seems whoever designed the new website theme has no idea what > > READABILITY means... It looks like someone just used some stupid online > > color picker, which just picks some similar colors to the one user > > chooses. The old website looked MUCH MUCH better. Imho, it's a > > regression... > > Hm I like the new design, but I agree that readability might be a problem. > Let's see what other say. > > > > > PS: how to install dillo 2.1 claws-mail plugin? > > Just install claws and the dillo plugin from source or packages > depending on your distribution. > Then make sure that dillo-2.1 is the dillo binary in your PATH. Ok, I'll try.

15 years, 4 months

Dillo-dev search results for query "plugin"