Oh and this brings me to the history anchor bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=565008
I filed it a LONG time ago ... and it's still not fixed in latest FF
back then Chrome and Safari got it right (maybe even IE), but not FF
so x years after that I am thinking about reverting the css frames
because of above to plain page ... (I was optimistic that they will fix
it quickly ... bah :( )
since for this prob I didn't even find a hack yet ;)
so I agree that it's hard to get it done 100% correctly
--
L
On 18.1.2012 10:42, Lubos Kosco wrote:
On 18.1.2012 6:51, Jens Elkner wrote:
On Wed, Jan 18, 2012 at 12:39:27AM +0100, Lubos Kosco wrote:
Well
I agree with all your points, but you forgot about one small thing -
this is not ideally implemented world - and there is a client, too
Yepp.
Afaik Firefox had the cache problem back when we started hitting the
problem(I think it was upgrade from 0.8 to 0.9) and IE has it for ages.
Even if headers properly indicate the change, the cache will be used
and
not refreshed for css and js files (there are even some hardcodes like
e.g. a week until the cache check is forced, etc.) .
I'm not convinced. IMHO at least modern browsers follow specifications,
but they may interpret things differently (optimized), if the server
does not clearly tell them the facts/its intention. If nothing special
happens, I'll try to do some checks/research on this at this weekend ...
please do, we use stock tomcat6 inside Solaris 11
at that time I think we checked headers and they properly sent
modified date, but since the filename didn't change browser didn't
refresh and people complained about broken page (back then it was some
older FF, probably 4 or 5 ? )
I know that is a dirty hack ... but IT WORKS for MOST of people.
And this is exactly what brought us the "You need the MS IE to properly
see this page" and still strikes Mozilla/Opera/etc users, just because
"designers" thought, it is a good thing to ignore standards and just
code it in a way, that it works for "most" people ...
So yes, some concession wrt. to non-essential stuff like making the UI
look a little bit better are ok, but somewhere a line needs to be drawn.
Fakeing static content to look like dynamic content is simply wrong ...
(a police officer jokes jumps right into my mind: it looks like ..., it
smells like ..., it tastes like ... - ooops :))
I totally agree, but back than it was the only way - alternative is we
will have a version of style sheet in its name and do renaming before
release (which is a developer burden and I don't see why developer
should pay for broken spec implementations)
And browsers DO cache it even with parameters, just test it, you'll
see.
Yes, I'll test. If it is the case, a filter should be implemented, which
adds appropriote headers to make sure, that the client understands, what
the server wants.
isn't this unnecessary overhead? we might just as well send the param
everytime and avoid checks
I know you mean it to be properly done - and I DO LIKE that approach.
Things should be proper, if everybody plays well. Does everybody
play well?
There is one more point of view - it has to work out of box (tm) and
for
99% of target audience.
Hmmm, 99% is a high goal for more or less sophisticated UIs/browsers.
So one should invest more time in investigating the root cause instead
of simply targeting the symptoms. Also I think, the target audience are
not business people, so assuming they are somehow disabled when using
its preferred tools might mislead as well.
true, most of people back then eventually figured out a FORCED
refresh, some of them even timed out the cache (let the problem be and
cache timeout solved it for them in a week or two :-D )
How does one achieve that?
Definitely not by forcing someone to change, but to change yourself. To
bend the spoon, you have to bend yourself ... even if it means not to
play 100% by rules, but still in certain boundaries ;)
Somehow: bending a little bit is ok, but taking its brain completely
offline and becoming a robot leads to undesirable development (former
GDR citizen know what I mean ;-)).
well ... that was the least effort solution at that time & trust me, I
did research on caching and how it's (was) implemented in popular
browsers
and I wasn't happy about that situation ...
Look, if you figure out some tomcat/glassfish option that will do
proper thing (or confirm that it works out of box),
also if you confirm latest FF, IE, Chrome and Safari (and Opera :) )
finally got the caching right I would be happy to not add the hack
but otherwise it's a must, since I'd like to avoid people mailing
admins of grok servers with silly css/js related problems
thnx for your help
L
hmm?
Yes.
Cheers,
jel.
On 18.1.2012 0:13, Jens Elkner wrote:
On Tue, Jan 17, 2012 at 04:25:16PM +0100, Lubos Kosco wrote:
I have a stopper
Jens changed the way how we include stylesheets
http://src.opensolaris.org/source/diff/opengrok/trunk/web/httpheader.jspf?r2=%2Fopengrok%2Ftrunk%2Fweb%2Fhttpheader.jspf%401186%3Aa7c1c479ae41&r1=%2Fopengrok%2Ftrunk%2Fweb%2Fhttpheader.jspf%401174%3A09f0768a7ec1
- Jens that was there for a reason - if the stylesheet just says
Yes, I changed it for reason as well: to allow propper caching.
IMHO it
is just plain wrong, to make static content appear "dynamic" and thus
uncachable just because a strange setup (proxy in front) or server
does
the wrong thing.
style.css without version, browser will not replace its copy upon
opengrok update and has stale cache !
Well, not sure what tomcat does, but since glassfish is using a lot of
tomcat stuff, I think the behavior is not different: They send
Etags and
Last-Modified-Dates. The browser asks the server to send the file,
if it
has been modified since the last modified date the browser knows about
or the Etag changed. Both is the case, when the file has been changed
(or one needs to put a lot of work into the app, to fake it to
appear as
it was sent last time). E.g:
REQUEST:
--------
Host src.iws.cs.ovgu.de
User-Agent Mozilla/5.0 (X11; SunOS i86pc; rv:7.0.1) Gecko/20100101
Firefox/7.0.1
Accept text/css,*/*;q=0.1
Accept-Language de-DE,de;q=1.0,en-US,en;q=0.8,de-DE;q=0.5,de;q=0.3
Accept-Encoding gzip, deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection keep-alive
Referer http://src.iws.cs.ovgu.de/source/xref/opengrok/
Cookie OpenGrokProject=opengrok; OpenGrokSorting=relevancy
If-Modified-Since Fri, 20 May 2011 19:30:26 GMT
If-None-Match W/"13344-1305919826000"
Cache-Control max-age=0
RESPONSE:
---------
X-Powered-By Servlet/3.0 JSP/2.2 (GlassFish Server Open Source
Edition 3.1 Java/Sun Microsystems Inc./1.6)
Server GlassFish Server Open Source Edition 3.1
Etag W/"13344-1305919826000"
Date Tue, 17 Jan 2012 22:51:51 GMT
CACHE:
------
Last Modified Tue Jan 17 2012 23:51:51 GMT+0100 (CET)
Last Fetched Tue Jan 17 2012 23:51:51 GMT+0100 (CET)
Expires Sat Feb 11 2012 04:59:59 GMT+0100 (CET)
Data Size 13344
Fetch Count 66
Device disk
So IMHO it seems to be a proxy misconfiguration or one should
configure
the server to provide Etags.
so above changeset should be checked for regressions and at least
style
sheet versioning using ?xxx has to come back !
IMHO not.
Regards,
jel.
On 17.1.2012 16:16, Knut Anders Hatlen wrote:
Vladimir Kotal<vladimir.ko...@oracle.com> writes:
On 01/16/12 16:18, Knut Anders Hatlen wrote:
Trond Norbye<trond.nor...@gmail.com> writes:
Or is anyone working on fixing this?
I guess the lack of response answers this question...
As to the question about reverting the changes, does anyone
know what
would be the minimum to back out in order to get the old behaviour
back?
The UI changes came in as part of a pretty big refactoring
patch, IIRC,
and probably many of the changes that have gone in later depend
on the
refactoring, so reverting the UI stuff isn't necessarily easier
than
fixing it.
Only couple of minor changes are necessary to fix the UI. I am
going
to fix the '..' link.
I've changed the style sheets so that the browser's default fonts
are
used, which seems to fix the issue with too big fonts. (Not sure it
fixed the related issue with too small fonts mentioned in the bug
report. Vlad, you might want to double-check that.)
That leaves only two issues to be fixed on bug #19105, I think:
1) Missing white lines between code lines (perhaps not a stopper?)
2) Garbled headers in Internet Explorer
_______________________________________________
opengrok-discuss mailing list
opengrok-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opengrok-discuss
_______________________________________________
opengrok-discuss mailing list
opengrok-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opengrok-discuss
_______________________________________________
opengrok-discuss mailing list
opengrok-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opengrok-discuss
_______________________________________________
opengrok-discuss mailing list
opengrok-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opengrok-discuss
