Unintended wrapping in event text in Firefox 3.0.1
Mike
Is anyone else experiencing issues with events spontaneously wrapping
text?
Here's a comparative screenshot of Safari v. Firefox 3 on Mac OS 10.5:
http://bit.ly/45VlHj
I have yet to test this on PC or Linux Firefox 3.
Knowing the cause would be great--finding a fix would be even better!
Thanks,
Mike
Mike
trunk, r1420.
Safari 3.1.2 behaves as expected, and Firefox 3.0.1 wraps, causing a
messy, crowded layout.
David Huynh
by "rendering" it in an invisible element off screen and then getting
that element's width. If there is any discrepancy in how CSS styles are
cascaded to that element compared to the actual label that you see, then
this width calculation would be wrong, leading to the label getting wrapped.
If you look in
http://static.simile.mit.edu/timeline/api-2.0/scripts/original-painter.js
and search for
this._frc.computeSize
That's where those widths get measured. FRC stands for
FontRenderingContext and is implemented at the end of
http://static.simile.mit.edu/ajax/api-2.0/scripts/graphics.js
As a test, you could override
SimileAjax.Graphics._FontRenderingContext.prototype.computeSize
and, say, add 5 to the returned width. That'd probably fix it, though
that's fixing the symptom than the cause.
David
Jon Crump
I got the unwanted label text wrapping in FF 3.0.1 also, and not in
Safari. David's fix described below works (of course), though I couldn't
say why ;-(
Jon
David Huynh
unpredictable ways and our Web APIs will break. I know for a fact that
IE 8 will completely break Exhibit 2.0 (and the fix is quite trivial).
The issue at hand is how to keep these APIs--Timeline, Exhibit,
Timeplot--up-to-date with regard to browser changes. It might not be
obvious to some but code bases need to be maintained or they will rot.
The problem is made worse by the following few factors:
- There have been contributions to the APIs that are for research
exploration rather than public use.
- I've fallen behind in terms of tracking how the code gets changed.
- We don't have automated tests for making sure that the APIs are not
broken by the latest code commits.
There have also been plenty of feature requests, but there is no
resource, and hence, no agenda to implement them.
I'm wondering if people have any preference / suggestion for how these
APIs should be maintained and served. If you or your company /
organization have any stake in these APIs, please let us know what you
think!
Thanks!
David
Nicolas Chauvat
On Thu, Aug 07, 2008 at 03:38:04PM -0700, David Huynh wrote:
> I'm wondering if people have any preference / suggestion for how these
> APIs should be maintained and served. If you or your company /
> organization have any stake in these APIs, please let us know what you
> think!
We have started delivering web apps that include the simile
widgets. We integrate them with our semantic web framework. Producing
software is what we do for a living, hence we are used to testing,
releasing, versioning, etc.
Event if there is no automated testing yet, the very first thing would
be to make sure that there are branches in the svn and that people
understand that they can now commit to the stable branch the changes
that are incompatible or just meant to explore new possibilities.
The second thing is to make sure that the version number reflects the
code-line.
As for serving the files, find a unique place and advertise it to
minimize reloads when user browse from one site to the next. Then read
http://highscalability.com/strategy-let-google-and-yahoo-host-your-ajax-library-free
and hope that Google, Yahoo, etc will soon feel the urge to host the
simile-widgets so that we don't have to take care of it any more :)
Hope this helps,
--
Nicolas Chauvat
logilab.fr - services en informatique scientifique et gestion de connaissances
Axel Hecht
>
> This actually brings up a larger problem: browsers change in
> unpredictable ways and our Web APIs will break. I know for a fact that
> IE 8 will completely break Exhibit 2.0 (and the fix is quite trivial).
"Some" browsers do ;-) For Firefox, we have incorporated a bunch of
tests from popular js libraries and run those continuously on our
current code base to keep exactly that from happening.
> The issue at hand is how to keep these APIs--Timeline, Exhibit,
> Timeplot--up-to-date with regard to browser changes. It might not be
> obvious to some but code bases need to be maintained or they will rot.
> The problem is made worse by the following few factors:
> - There have been contributions to the APIs that are for research
> exploration rather than public use.
> - I've fallen behind in terms of tracking how the code gets changed.
> - We don't have automated tests for making sure that the APIs are not
> broken by the latest code commits.
>
> There have also been plenty of feature requests, but there is no
> resource, and hence, no agenda to implement them.
>
> I'm wondering if people have any preference / suggestion for how these
> APIs should be maintained and served. If you or your company /
> organization have any stake in these APIs, please let us know what you
> think!
I'm afraid I had to say that tests are key. I myself hate writing
tests, but in the few cases I did so far, they uncovered bugs in my
implementations immediately, and keep me from introducing new ones.
I guess some features of exhibit et al could be tested with unit
tests, some might even work in just xpcshell.
An ad-hoc way to test exhibit could be to collect a bunch of exhibits
from the wild, make them self-contained and to then use something like
windmill, http://windmill.osafoundation.org/, to do some behavioral
tests. Like "loads right", shows that many items, this many facets,
clicking on that facet thingie reduces items to that...
That might not be as constructive in regression hunting, but it might
be a good start.
More on what Mozilla uses to test with loads of pointers can be found
on http://developer.mozilla.org/en/docs/Mozilla_automated_testing
Axel
David Huynh
> Hi,
>
> On Thu, Aug 07, 2008 at 03:38:04PM -0700, David Huynh wrote:
>
>> I'm wondering if people have any preference / suggestion for how these
>> APIs should be maintained and served. If you or your company /
>> organization have any stake in these APIs, please let us know what you
>> think!
>>
> We have started delivering web apps that include the simile
> widgets. We integrate them with our semantic web framework. Producing
> software is what we do for a living, hence we are used to testing,
> releasing, versioning, etc.
>
mailing list! :-) Is there any more detail about how your framework is
using our widgets? I'd love to know!
> Event if there is no automated testing yet, the very first thing would
> be to make sure that there are branches in the svn and that people
> understand that they can now commit to the stable branch the changes
> that are incompatible or just meant to explore new possibilities.
>
I hear you. We're a research group, so we have a tendency to get really
excited about research ideas and forget about code stability and such.
We can get carried away.
> The second thing is to make sure that the version number reflects the
> code-line.
>
Could you elaborate on this point? I'm not sure I get it.
> As for serving the files, find a unique place and advertise it to
> minimize reloads when user browse from one site to the next. Then read
> http://highscalability.com/strategy-let-google-and-yahoo-host-your-ajax-library-free
> and hope that Google, Yahoo, etc will soon feel the urge to host the
> simile-widgets so that we don't have to take care of it any more :)
>
Great idea! I actually gave a talk at Google NYC, so maybe I should
follow up with them and try to get free hosting.
David
David Huynh
> 2008/8/8 David Huynh <dfh...@alum.mit.edu>:
>
>> This actually brings up a larger problem: browsers change in
>> unpredictable ways and our Web APIs will break. I know for a fact that
>> IE 8 will completely break Exhibit 2.0 (and the fix is quite trivial).
>>
> "Some" browsers do ;-)
;-)
> For Firefox, we have incorporated a bunch of
> tests from popular js libraries and run those continuously on our
> current code base to keep exactly that from happening.
>
Can Simile widgets be counted among those "popular js libraries"?... :-)
After all, Exhibit does get used inside Mozilla.
> I'm afraid I had to say that tests are key. I myself hate writing
> tests, but in the few cases I did so far, they uncovered bugs in my
> implementations immediately, and keep me from introducing new ones.
>
Our ex-project manager was pushing hard for automated tests, too, but at
the time, I was able to keep track of everything myself and writing
tests would slow me down. Now that there are more contributors, and I'm
no longer full-time with Simile, I do realize the importance of a
process that includes automated testing.
> I guess some features of exhibit et al could be tested with unit
> tests, some might even work in just xpcshell.
>
I see... Maybe the database layer.
> An ad-hoc way to test exhibit could be to collect a bunch of exhibits
> from the wild, make them self-contained and to then use something like
> windmill, http://windmill.osafoundation.org/, to do some behavioral
> tests. Like "loads right", shows that many items, this many facets,
> clicking on that facet thingie reduces items to that...
>
> That might not be as constructive in regression hunting, but it might
> be a good start.
>
> More on what Mozilla uses to test with loads of pointers can be found
> on http://developer.mozilla.org/en/docs/Mozilla_automated_testing
>
Thanks for the pointers! I didn't know about Windmill before.
I'm wondering if other people who use Simile widgets in their production
systems, like Nicolas Chauvat, have already written some tests, and if
so, maybe we could reuse them rather than starting from scratch...
David
Nicolas Chauvat
I have done a bit of research myself. Thanks to your team for
providing us with such nice widgets under the BSD license.
On Sun, Aug 10, 2008 at 11:20:03PM -0700, David Huynh wrote:
> Nice to have people with your software engineer experience on the
> mailing list! :-)
Thanks for cheering up, but wait until we actually provide some help
;-)
> Is there any more detail about how your framework is using our
> widgets? I'd love to know!
We have a query language. Queries return resultsets. Depending on the
characteristics of the resultset (type of entities, number of
entities, interfaces implemented by entities, etc), different views
can be applied to generate an output. Output can be text (html, plain
text, xml, rss, etc) or binary (png, pdf, etc).
And of course output can be json to feed to the Simile widgets.
I gave a demo of this two years ago at SolutionsLinux in Paris, but
there were not many people that followed up with questions at the time.
> > The second thing is to make sure that the version number reflects the
> > code-line.
> >
> Could you elaborate on this point? I'm not sure I get it.
Our policy is to name versions with a triple: x.y.z.
x is for major changes (read incompatible changes, reorganizing the
codebase, etc.)
y is for minor changes (read adding new functionnalities, refactoring,
speedups, better doc, improvements, etc.)
z is for bugfix (read making sure something that was supposed to work
is actually working as advertised, but *no*new*feature*, improvement,
refactoring of any kind)
For example our framework is currently at 2.48.9 for the stable
version and the unstable version coming out this week will be 2.49.0.
We plan on a vast renaming within the next month and will move to 3.0.
> > As for serving the files, find a unique place and advertise it to
> > minimize reloads when user browse from one site to the next. Then read
> > http://highscalability.com/strategy-let-google-and-yahoo-host-your-ajax-library-free
> > and hope that Google, Yahoo, etc will soon feel the urge to host the
> > simile-widgets so that we don't have to take care of it any more :)
> >
> Great idea! I actually gave a talk at Google NYC, so maybe I should
> follow up with them and try to get free hosting.
That would be great. With the above policy for numbering versions, you
could go for something like:
http://ajax.googleapis.com/ajax/libs/simile-widgets/x/simile-something.js
http://ajax.googleapis.com/ajax/libs/simile-widgets/x.y/simile-something.js
http://ajax.googleapis.com/ajax/libs/simile-widgets/x.y.z/simile-something.js
And developers would include x.y.z if they depend on a specific
version, or include x.y if they want the latest one or just include x
if they feel really confident in this group's release management work.
Another good thing is that web developers include the full version
number would have to update their code more often but would allow for
faster downloads. For example version 1.2.3 only gets published once
and Google will set the expiration header to some time very far away
in the future... not expired means no reload by the browser. Load
once and reuse many times accross all apps using that library.
See http://code.google.com/apis/ajaxlibs/documentation/
David Karger
have noticed given his productivity, but DavidH was actually busy
working as a graduate student when he built these neat tools. I have
several graduate students who I expect will be continuing to pursue
research in similar directions. However, DavidH was exceptional in the
amount of time he invested and skill he demonstrated in making his code
robust and addressing user requests. The typical graduate student is
focused on building something that works just long enough for them to
graduate, and has not been trained in industrial software engineering
practices. So although I expect we will be producing a number of
interesting extensions to exhibit, and would love for some of them to be
adopted by this community, I do not expect our group to have the
resources or the skills necessary to keep the existing codebase robust
and "un-bitrotted".
-David
Nicolas Chauvat
>
> Perhaps it's worth throwing in the academic perspective. You may not
> adopted by this community, I do not expect our group to have the
> resources or the skills necessary to keep the existing codebase robust
> and "un-bitrotted".
Simile is great work. You released it under the BSD license and we, as
a community of developers delivering software to end-users, will try
to make sure it does not "bit-rot" and get the usage it deserves.
Thank you for your work.
David Huynh
> ... we, as a community of developers delivering software to end-users, will try
> to make sure it does not "bit-rot" and get the usage it deserves.
>
action, take charge, as you see fit!
David
LarryK
Hi Mike,
Have you submitted a bug report to the Firefox team?
Can you post the exact html that you use to demonstrate the difference
between the browsers with respect to this issue?
Thanks,
Larry
LarryK
I just downloaded and installed FF 3.0.1 on Windows.
I tested the trunk version of the Timeline libraries with it and I
don't see the wrapping problem that you've encountered. Is it still
happening for you?
I used the jfk timeline. An event name of
FBI tells Thomlinson stay quiet
is pretty long, but it displays properly both in the main timeline and
in the popup.
Does your page load any CSS that could be interfering with the
Timeline calculations/display?
===>>> Hello fellow readers, has anyone else seen the problem that
Mike is having? (See first post in this thread.)
Regards,
Larry
Jon Crump
snip
> ===>>> Hello fellow readers, has anyone else seen the problem that
> Mike is having? (See first post in this thread.)
>
> Regards,
>
> Larry
Yes. I posted a +1 on Aug. 1. I fixed it by hijacking the function
SimileAjax.Graphics._FontRenderingContext.prototype.computeSize per
David's suggestion of Jul. 28:
> If you look in
> http://static.simile.mit.edu/timeline/api-2.0/scripts/original-painte...
> and search for
> Â Â this._frc.computeSize
> That's where those widths get measured. FRC stands for
> FontRenderingContext and is implemented at the end of
> Â Â http://static.simile.mit.edu/ajax/api-2.0/scripts/graphics.js
> As a test, you could override
> Â Â SimileAjax.Graphics._FontRenderingContext.prototype.computeSi
> and, say, add 5 to the returned width. That'd probably fix it, though
> that's fixing the symptom than the cause.
As he suggested, this fixed the symptom. You can see a comparison here:
This calls a js page JohnItinerary.js with the above fix implemented:
http://home.myuw.net/jjcrump/Timelines/itinerary/JohnItinerary.html and
it's rendered correctly in both safari and FF.
This:
http://home.myuw.net/jjcrump/Timelines/itinerary/FFwrappingTest.html
calls the js at FFwrappingTest.js with the hijacked function commented
out. Safari 3.1.2 renders the event labels correctly, FF 3.0.1 wraps them.
Note that these pages are calling the static timeline 2.0 api at
http://static.simile.mit.edu/timeline/api-2.0/timeline-api.js
Allow me to add my 'me too' again, in the hope that someone with deeper
browser knowledge will know how to file the bug with FF if that's where
the problem lies.
Jon
LarryK
On Sep 9, 6:20 pm, Jon Crump <jjcr...@u.washington.edu> wrote:
Hi Jon,
Windows or Mac?
If on Mac, can you test on Windows to see if the original problem is
Mac-specific?
Thanks,
Larry