After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 121118 - Gconf-option "Always use the desktop theme colors" breaks display of images
Gconf-option "Always use the desktop theme colors" breaks display of images
Status: RESOLVED NOTGNOME
Product: epiphany
Classification: Core
Component: [obsolete] Backend:Mozilla
0.x
Other Linux
: High major
: ---
Assigned To: Epiphany Maintainers
Marco Pesenti Gritti
: 122978 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-08-31 16:25 UTC by Mario Vukelic
Modified: 2005-12-31 18:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot of FootNotes with wrong image display (226.87 KB, image/png)
2003-08-31 16:27 UTC, Mario Vukelic
Details
Screenshot of /. with wrong image display (325.61 KB, image/png)
2003-08-31 16:28 UTC, Mario Vukelic
Details
Screenshot of Gnome.org with wrong image display (137.63 KB, image/png)
2003-08-31 16:28 UTC, Mario Vukelic
Details
~/.gnome2/epiphany/mozilla/epiphany/prefs.js of problem user (2.25 KB, text/plain)
2003-09-01 18:31 UTC, Mario Vukelic
Details

Description Mario Vukelic 2003-08-31 16:25:28 UTC
Epiphany does not display all images for me. See the screenshots of
http://www.gnomedesktop.org/ , http://slashdot.org/ and
http://www.gnome.org/ I attach below.

In gconf, /apps/epiphany/filtering/image_loading_type is set to "0", as I
think it should be.

This happens to me nearly always, and on every site I tried until now.
"Nearly", because once it happened that after clicking a link on
gnomedesktop.org, everything displayed correctly, and stayed ok also fo
other sites, until I closed epiphany. Then it was back to normal, i.e.,
wrong display
Comment 1 Mario Vukelic 2003-08-31 16:27:23 UTC
Created attachment 19628 [details]
Screenshot of FootNotes with wrong image display
Comment 2 Mario Vukelic 2003-08-31 16:28:22 UTC
Created attachment 19629 [details]
Screenshot of /. with wrong image display
Comment 3 Mario Vukelic 2003-08-31 16:28:53 UTC
Created attachment 19630 [details]
Screenshot of Gnome.org with wrong image display
Comment 4 Marco Pesenti Gritti 2003-08-31 18:39:08 UTC
Can you try to remove .gnome2/epiphany/.../prefs.js ? That gconf key
is no more used, maybe you had it enabled or something.
Comment 5 Mario Vukelic 2003-08-31 19:22:09 UTC
I'm no sure I understand your suggestion, because you're talking about
prefs.js, and then say "that gconf key is no more used". However,
prefs.js is not a gconf key :)

Anyway, I removed ~/gnome2/epiphany/mozilla/epiphany/prefs.js which
changed nothing - still wrong
Comment 6 Marco Pesenti Gritti 2003-08-31 20:15:26 UTC
Just looked at shots urgh, even the image colors are wrong. Does it
work correctly with mozilla itself (the same mozilla you compiled
epiphany with). Can you attach your prefs.js ?
Comment 7 Mario Vukelic 2003-08-31 20:46:18 UTC
Mozilla (the one used by epiphany) works ok, so does galeon. The issue
with epiphany exists for me with every epi version I tried.

Epi works ok for all other users.

I can't attach my user's prefs.js, as I deleted it :) Also, it
probably doesn't matter, since even when I moved ~/.gnome2/epiphany
away, the problem still exists.  Something in gconf perhaps?
Comment 8 Marco Pesenti Gritti 2003-09-01 12:17:20 UTC
prefs.js is regenerated every time on startup from the gconf prefs, it
contains all mozilla related prefs, so it's more likely to have
relevant info.

Still, if you can try it with a test user could help to exclude it's a
prob in the configuration.
Comment 9 Mario Vukelic 2003-09-01 18:27:55 UTC
As I said in my previous comment, it works ok for all other users,
also for a test user I created for the purpose. I'll attach my regular
users's prefs.js
Comment 10 Mario Vukelic 2003-09-01 18:31:00 UTC
Created attachment 19649 [details]
~/.gnome2/epiphany/mozilla/epiphany/prefs.js of problem user
Comment 11 Marco Pesenti Gritti 2003-09-01 22:04:52 UTC
The only thing that sounds sort of related to me is
user_pref("browser.display.use_document_colors", false);
which is "Always use system colors" in the prefs dialog.
Comment 12 Mario Vukelic 2003-09-02 05:20:12 UTC
It's called "Always use the desktop theme colors" - but yes, this was
it. Turning it off and reloading the page fixes the problem. This
behavior does not depend on the theme AFAICT.
Comment 13 Marco Pesenti Gritti 2003-09-02 08:27:01 UTC
Can you try if checking bot "Use system colors" and "use my chosen
colors...) in mozilla colors page give the same result ? In that case
it's a mozilla bug.
Comment 14 Mario Vukelic 2003-09-02 17:40:34 UTC
There you go, "use my chosen colors..." in mozilla has the same
effect. Similar report is there
http://bugzilla.mozilla.org/show_bug.cgi?id=183783

However, it complains only that "use my chosen colors..." was the
default, although it gives horrible results. I tend to think that a
setting that gives horrible result is stupid anyway (it's like an
option "make this app suck"), but maybe Mozilla can justify this
setting, since it is not inteded to be an end user browser. Given the
goals of epiphany, I'd think it should not offer that option until
setting it gives usable results. Or is there actually any use case for
the option in this state, which seems just broken to me?
Comment 15 Marco Pesenti Gritti 2003-09-02 17:53:48 UTC
The option is absolutely necessary for accessibility. I'm actually
wondering if not showing some images is intentional for that reason.
It make sense for the background images (on gnomedesktop) but it
doesnt for the logo on gnome.org which seem a normal image.
Comment 16 Marco Pesenti Gritti 2003-09-02 17:55:05 UTC
One thing we could consider like a problem is that it could be hard to
understand what happened if you enable it by mistake.
Comment 17 Mario Vukelic 2003-09-02 18:50:23 UTC
Maybe just a wording change ist needed? Both "Always use the desktop
theme colors" and "use my chosen colors..." provoke the naive reaction
of "well, sure I want my complete desktop to look consistent",
especially right now when linux desktop consistency is such a big
topic. Which probably was the reason I enabled it in the first place.
Even more so since "Always use the desktop theme colors" is under the
innocent-looking header "Colors". 

Is accessibility the /only/ reason for it? Then:

Current:
---------------------------------------
Colors
|_| Always use the desktop theme colors
---------------------------------------


Suggestion:
---------------------------------------------
Accessibility
|_| Desktop theme colors override page colors
---------------------------------------------


Comment 18 Marco Pesenti Gritti 2003-09-22 18:31:04 UTC
Dave, opinions ?
Comment 19 Dave Bordoley [Not Reading Bug Mail] 2003-09-22 18:34:57 UTC
Yeah a rewording is probably in order. Not quite sure what it should 
be. Maybe an accessibility tab, with that pref, the caret pref is in 
order? I'm feeling insecure these days about most stuff...ask seth I 
guess :)
Comment 20 Marco Pesenti Gritti 2003-09-22 18:38:02 UTC
Hm for new pages creation I'd prolly wait until 1.2 ui is more
definite. And stop to be unsecure damn you ;)
Comment 21 Dave Bordoley [Not Reading Bug Mail] 2003-09-22 18:41:40 UTC
> Hm for new pages creation I'd prolly wait until 1.2 ui is more
> definite. 

For sure, I think the porting work is definately more important right 
now. Also this pref defaults to off right? I guess the string I chose 
is poor. Maybe "Overide colors specified by webpages with Desktop 
defaults." Although that is pretty wordy eccchhhh. 

> And stop to be unsecure damn you ;)

Its probably just a phase. btw 1.1 is looking nice :)
Comment 22 Marco Pesenti Gritti 2003-09-22 21:52:17 UTC
`Allow documents to use _other fonts' is intended to eventually have
siblings 
in `Allow documents to use _other colors' and `Allow documents to use
_other 
styles'. Not all pages are written by authors.

This is what mpt was suggesting in a mozilla bug. We have the
additional problem of the desktop theme colors ...
What about
"Allow documents to use their own colors" or
"Allow documents to specify colors".
I think this at least make clear that you are going to break documents
colors ...
Comment 23 Christian Persch 2003-09-22 22:02:20 UTC
*** Bug 122978 has been marked as a duplicate of this bug. ***
Comment 24 Marco Pesenti Gritti 2004-01-26 18:26:39 UTC
Dave, it's time to solve this ? What we do ?
Comment 25 Dave Bordoley [Not Reading Bug Mail] 2004-01-26 18:48:20 UTC
Since we don't want to make any "large" changes (ie a11y tab) lets 
just do a label change to "Desktop theme colors override page colors" 
as the reporter suggested above. longer term we can do the style 
sheet thing maybe, but thats for another day to discuss.
Comment 26 Marco Pesenti Gritti 2004-01-26 18:50:57 UTC
I'm just worried "override" is a technical term most people dont
understand which could be completely wrong given my english knowledge.
If so maybe you can fix it and close this :)
Comment 27 Dave Bordoley [Not Reading Bug Mail] 2004-01-26 19:49:29 UTC
yeah its is somewhat technical true. Ugghh...maybe seth or calum will 
have a better suggestion.
Comment 28 Calum Benson 2004-01-27 15:55:12 UTC
Agree "override" is a bit technical... I'm thinking a pair of radio
buttons might actually be the clearest:

  Use these colors for drawing pages:
  ( ) All available colors
  (o) Desktop theme colors only

Otherwise you end up with something like:

  [x] Use desktop theme colors only when drawing pages
or
  [x] Only use desktop theme colors when drawing pages

where the word "only" makes the sentence rather ambiguous in each case :)
Comment 29 Mario Vukelic 2004-01-27 18:54:58 UTC
As the OP, Calum's idea seems the clearest to me as for how to phrase
the option itself.
However, much of _my confusion came from the fact that the location at
which the option is placed atm is under the heading "Colors" in the
"Fonts and Colors" tab. As the discussion of the bug has shown that
the only use case for the option seems to be accessibility, I think
that making this clear is as important as an unambiguous wording of
the option itself. I would combine my suggestion from above with
Calum's and change the "Colors" heading to "Accessibility"
Comment 30 Calum Benson 2004-01-29 14:18:59 UTC
Sure, I meant to say I agreed with the 'Accessibility' change too :)
Comment 31 Chris Lahey 2004-02-19 20:14:24 UTC
Wouldn't all of these fixes require string or gui changes which we're
too late for for 1.2?
Comment 32 Dave Bordoley [Not Reading Bug Mail] 2004-02-19 20:31:21 UTC
Yeah, moving to 1.4.
Comment 33 Zack Cerza 2004-08-11 16:07:01 UTC
Using Epiphany 1.2.6 I only see a "Always use the desktop theme colors"
checkbox, which seems like a good idea. I'm only missing background images,
which seems appropriate; status on this bug?
Comment 34 Christian Persch 2004-08-11 18:30:52 UTC
Using epiphany with moz 1.7, I can still reproduce the problem. Since I can also
repro in mozilla (set browser.display.use_document_colors to false in
about:config), this seems like a mozilla problem. We need to see if it's been
filed yet on b.m.o.
Comment 35 Christian Persch 2004-08-23 12:58:28 UTC
Moving Target Milestone -> 1.6 because of string freeze.
Comment 36 Christian Persch 2004-08-23 15:10:31 UTC
-> Mozilla interaction
Comment 37 Christian Persch 2004-10-13 10:54:47 UTC
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
Comment 38 Elijah Newren 2004-10-27 16:41:21 UTC
String freeze is over, so I'm removing the BLOCKED_BY_FREEZE keyword.
Comment 39 Crispin Flowerday (not receiving bugmail) 2005-12-31 18:21:41 UTC
This bug is reported upstream as:

https://bugzilla.mozilla.org/show_bug.cgi?id=306625

which is related to:

https://bugzilla.mozilla.org/show_bug.cgi?id=19260
Comment 40 Crispin Flowerday (not receiving bugmail) 2005-12-31 18:29:09 UTC
Closing as NOTGNOME as this is a mozilla bug (see previous comment)