Reporting Issues

View active issues, report bugs and contribute feature requests through our issues tracking system. Alternatively we also accept bug reports or feature requests through the mailing-list.

Recent Updates

• Issue 708 created: "JQDialog>>#buttons:" 2012-01-24T11:35:42+00:00
  I think that the parameter name and comment is misleading for JQDialog>>#buttons: Current it reads: ---- buttons: anArray "Specifies which buttons should be displayed on the dialog. Each element of the array must be an Object defining the properties to set on the button." self optionAt: 'buttons' put: anArray ---- IIUC #buttons should take a dictionary so read: ---- buttons: aDictionary "Specifies which buttons should be displayed on the dialog. The keys of the dictionary define the text to display on the button and the values of the dictionary define the action to be taken when the button is pressed" self optionAt: 'buttons' put: aDictionary ---- I check-in a change myself, but I remember that some of the Seaside jQuery integration is automated so would the change be overwritten by an automated update?
• Update 7 to issue 701 ("HTML5 Tags have superfluous space") 2012-01-24T06:31:13+00:00
  Name: Seaside-HTML5-pmm.28 Author: pmm Time: 24 January 2012, 7:30:51 am UUID: 75c03738-39b6-4138-8857-2fd11a8ebb32 Ancestors: Seaside-HTML5-NickAger.26 - Issue 701: HTML5 Tags have superfluous space Status: Fixed
• Update 6 to issue 701 ("HTML5 Tags have superfluous space") 2012-01-24T06:26:25+00:00
  Name: Seaside-HTML5-pmm.30 Author: pmm Time: 24 January 2012, 7:24:43 am UUID: a2ba133b-3076-4e57-9894-eb1d2f8afe4f Ancestors: Seaside-HTML5-pmm.29 - Issue 701: HTML5 Tags have superfluous space Labels: HTML5
• Update 5 to issue 701 ("HTML5 Tags have superfluous space") 2012-01-24T06:23:47+00:00
  Summary: HTML5 Tags have superfluous spaceLabels: -Seafox Version-Seaside3.0
• Update 4 to issue 701 ("HTML5 Tags don't have superfluous space") 2012-01-24T06:22:17+00:00
  Hi Philippe, I've just got round to fixing some bugs in Seafox - namely trying to work out why: <section> <header> <h1>foo</h1> </header> <p>bar</p> </section> gets translated as: "Unrecognised element 'section'" (html tag: 'section') with:[ "Unrecognised element 'header'" (html tag: 'header') with:[ html heading level: 1; with: 'foo' ]. html paragraph: 'bar' ] The reason is that WAHtmlCanvas>>#section and WAHtmlCanvas>>#header have an extra space or rather a CR at the end of their string, for example: self tag: 'header ' I guess that this isn't deliberate. Would you like me to correct it and check in a fixed version? The effected tags are: summary header section footer In the meantime I'll add a call to #withoutTrailingBlanks to Seafox htmlElements Cheers Summary: HTML5 Tags don't have superfluous spaceStatus: StartedOwner: philippe...@gmail.com
• Issue 707 created: "merge Grease-Pharo-Core-lr.45" 2012-01-22T16:32:30+00:00
  Grease-Pharo-Core-lr.45 needs to be merged from Seaside 3.0. It fixes some typical uses of Seaside-REST. We should also come up with some unit tests to reproduce the issue.
• Update 1 to issue 699 ("GRPharoPlatform>>#write:toFile:inFolder: uses CrLfFileStream in seaside 3.0.6.3") 2012-01-22T15:01:09+00:00
  Name: Grease-Pharo-Core-pmm.45 Author: pmm Time: 22 January 2012, 3:58:58 pm UUID: 458930d3-97b2-42c2-86d9-163b972f7f44 Ancestors: Grease-Pharo-Core-pmm.44 - Issue 699: GRPharoPlatform>>#write:toFile:inFolder: uses CrLfFileStream in seaside 3.0.6.3 Name: Grease-Tests-Pharo-Core-pmm.14 Author: pmm Time: 22 January 2012, 4:00:25 pm UUID: 3b417409-7b1e-47a5-9601-4931425fb496 Ancestors: Grease-Tests-Pharo-Core-lr.13 - Issue 699: GRPharoPlatform>>#write:toFile:inFolder: uses CrLfFileStream in seaside 3.0.6.3 Status: FixedOwner: philippe...@gmail.comLabels: -Priority-Medium Priority-Low Platform-Pharo Version-Seaside3.1
• Issue 706 created: "Consider removing WADivTag" 2012-01-22T14:27:23+00:00
  Now that we have removed WADivTag >> #clear we can replace it with WAGenericTag
• Update 3 to issue 701 ("Added WAHeaderTag & friends to Seaside-Html5") 2012-01-22T14:23:46+00:00
  The rule of thumb is everything that needs more methods than are on WAGenericTag gets its own subclass of WATagBrush. If WAGenericTag is enough then it's gonna be WAGenericTag. Labels: -Priority-Medium Priority-Low Seafox
• Issue 705 created: "review WAUrl >> #=" 2012-01-22T14:09:16+00:00
  While WAUrl >> #= is simple and correct it is not ideal because it compares the string representation of both objects with means lots of allocation. Together with a suboptimal #hash this can cause bad performance.
• Issue 704 created: "review WAUrl >> #hash" 2012-01-22T14:05:33+00:00
  WAUrl >> #hash considers much less information that WAUrl >> #=. For example #= does not consider the scheme port or parameters. For examples (WAUrl absolute: 'http://localhost/conter') ~= (WAUrl absolute: 'http://localhost:8080/conter') but (WAUrl absolute: 'http://localhost/conter') hash = (WAUrl absolute: 'http://localhost:8080/conter') hash
• Update 2 to issue 701 ("Added WAHeaderTag & friends to Seaside-Html5") 2012-01-20T16:41:54+00:00
  Sure. But I didn't know the justification for why some Html5 elements got their own subclasses of WATagBrush and others only got a method on the WAHtmlCanvas. I posted this here because it seemed to me that those additional subclasses may be more useful than only as a extension to the Seafox package.
• Update 1 to issue 701 ("Added WAHeaderTag & friends to Seaside-Html5") 2012-01-20T16:32:36+00:00
  hmm this seems like more of a bug with Seafox
• Update 2 to issue 703 ("Add support for X-FRAME-OPTIONS") 2012-01-19T08:37:44+00:00
  This is not how I understand the post. It says "if you can edit the pages you're trying to iframe (eg., they're your own pages)" and then goes on to add an HTTP header to the response. The equivalent would be to run Smalltalk code in the image.
• Update 1 to issue 703 ("Add support for X-FRAME-OPTIONS") 2012-01-19T04:32:42+00:00
  I haven't checked it for myself but did see that the X-FRAME-OPTIONS may be able to be overridden on the attackers page: http://stackoverflow.com/a/6767901
• Issue 703 created: "Add support for X-FRAME-OPTIONS" 2012-01-18T18:31:28+00:00
  It would be nice if we had support for X-FRAME-OPTIONS to prevent Seaside applications from being framed. https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_response_header
• Update 1 to issue 702 ("Broken dependency in Seaside-Tests-HTML5-Tags") 2012-01-16T19:05:04+00:00
  Oops -- dup of 691 (which was mine also). Status: Duplicate
• Issue 702 created: "Broken dependency in Seaside-Tests-HTML5-Tags" 2012-01-16T17:28:12+00:00
  WAHtml5ElementsTest in Seaside-Tests-HTML5-Tags references WAToolFiles which is defined in Seaside-Tools-Web, but Seaside-Tests-HTML5-Tags is not (and should not be) dependent on Seaside-Tools-Web. This results in an error when loading Seaside-Tests-HTML5-Tags on VA Smalltalk. The solution is to change SeasideHtml5ElementsTest>>#renderFigureOn: to use an image from WATestingFiles (which is in the dependency chain).
• Issue 701 created: "Added WAHeaderTag & friends to Seaside-Html5" 2012-01-14T20:21:39+00:00
  I've been using Nick Ager's Seafox code on Html5 docs and wanted it to output html header:[]. rather than: html tag:'header' with:[] In the attached package I went through the *seaside-html5 extensions to the WAHtmlCanvas and added classes for each tag that didn't have one. So WAHtmlCanvas>>#header ^self tag: 'header' becomes WAHtmlCanvas>>#header ^self brush:WAHeaderTag new With this seafox outputs what I want.
• Issue 700 created: "JQScriptGenerator changes event attribute methods so they don't create the attribute" 2012-01-12T21:49:53+00:00
  Philippe and I were discussing this at ESUG - it's been sitting in my email inbox as a todo since then so I want to put it here so it isn't lost. We noticed that all the event attribute methods on WATagBrush (#onChange, #onSelect:, etc) delegate through the script generator and that JQScriptGenerator implements #event:do:on: such that the attribute requested is never actually created (IDs are instead generated and load scripts are added). We weren't convinced this was very nice since behaviour on WATagBrush tends to be pretty low-level and fairly directly mapped to HTML. This implementation makes it tricker to generate specific HTML (you would have to resort to using #attributeAt:put:). Our suggestion was to have have the methods that map to attribute names simply set the attributes and have a higher-level interface that can make smarter decisions. Rather than implementing a duplicate set of methods for all the events, perhaps WATagBrush could simply implement #on:do:? (or #on:script: or similar? it's maybe better not to reuse #on:do: here...). The first parameter could be strings/symbols or maybe it would be nicer to have some kind of JSEvent object(s) that could be passed in?