Summary: | [GTK] Desktop proxy settings are ignored inside the internal jhbuild | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Mario Sanchez Prada <mario> | ||||||||
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | buildbot, cgarcia, commit-queue, gustavo, rniwa, svillar, zan | ||||||||
Priority: | P2 | Keywords: | Gtk | ||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Attachments: |
|
Description
Mario Sanchez Prada
2013-09-06 02:34:32 PDT
I guess the dconf module will be optional? Could the memory backend somehow be populated with the necessary information when the Jhbuild environment is initialized? For instance passing values for specifically listed keys from the outside environment's settings into the fresh memory backend using `gsettings set ...`? Created attachment 210715 [details]
Patch proposal
This is the patch implementing the proposed solution.
I've tested it extensively here and works great, responding as expected in all possible proxy situations: none, auto and manual. This patch fixes such a painful situation when developed behind a proxy, so I personally would appreciate if we could get it reviewed soon :-D
/me grins twice
(In reply to comment #2) > Created an attachment (id=210715) [details] > Patch proposal > > This is the patch implementing the proposed solution. > > I've tested it extensively here and works great, responding as expected in all possible proxy situations: none, auto and manual. This patch fixes such a painful situation when developed behind a proxy, so I personally would appreciate if we could get it reviewed soon :-D > > /me grins twice As commented in private IRC I'd prefer not to add dconf and instead add something to the jhbuildrc (likely using gsettings gobject introspection) to read the proxy settings (from the system or from the "classic" http_proxy env var) and update the gsettings memory backend. Comment on attachment 210715 [details] Patch proposal Attachment 210715 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/1714148 New failing tests: media/video-object-fit.html Created attachment 210724 [details]
Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-15 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.4
(In reply to comment #3) > [...] > As commented in private IRC I'd prefer not to add dconf and instead add > something to the jhbuildrc (likely using gsettings gobject introspection) > to read the proxy settings (from the system or from the "classic" > http_proxy env var) and update the gsettings memory backend. We already discussed that idea here but the problem we found is that checking the http_proxy env var won't fix the problem if you don't have it set up in your system, even when you have the desktop proxy settings set in gsettings. Besides, that will work fine as long as you are ok with setting up an http(s) proxy, but we would need to add support for more variables if we wanted to support other things, such as autoconfig URLs (e.g. auto_proxy env var). In any case, after realizing that the original approach has not been very well received, perhaps I should give this idea a try and see how it works. Created attachment 210766 [details] Patch proposal After some investigation, I realized that we can not use the trick of setting some configuration values in the memory backend from jhbuildrc (as suggested, based on the presence of the typical environment variables) because the memory backend provides in-process persistence only, and the jhbuild shell is not actually the process we are interested in, but the apps we launch in that environment (e.g. MiniBrowser), which won't read anything we set from jhbuildrc. So, after talking to Gustavo in IRC, we believe that a better approach that will make lives easier for everybody without compromising the default configuration, would be to add dconf as an optional jhbuild module AND remove the line from jhbuildrc that explicitly sets the memory backend just for the sake of removing the usual warning you will see letting you know about that. That way, someone willing to use the default behaviour won't have to do anything different and just will get that warning (which IMHO is useful anyway, to remind you what you are using), and someone willing to have access to the global settings will just have to run Tools/jhbuild/jhbuild-wrapper --gtk build dconf previously, pretty much as it's mentioned in https://trac.webkit.org/wiki/WebKitGTK/StartHacking#PersistentGSettings. Comment on attachment 210766 [details] Patch proposal View in context: https://bugs.webkit.org/attachment.cgi?id=210766&action=review > Tools/gtk/jhbuildrc:-61 > -# We often end up using the memory backend anyway, so explicitly choosing > -# it will prevent the warning message. > -os.environ['GSETTINGS_BACKEND'] = 'memory' > - Maybe we could convince the gsettings people to drop or provide a way to disable the warning, but it's not that big of a problem. Comment on attachment 210766 [details]
Patch proposal
Thanks Gustavo!
Comment on attachment 210766 [details] Patch proposal Clearing flags on attachment: 210766 Committed r155197: <http://trac.webkit.org/changeset/155197> All reviewed patches have been landed. Closing bug. |