ACK 106-1 and 111. See comments below.
On 3/16/2012 9:41 AM, Petr Vobornik wrote:
On 03/13/2012 10:54 PM, Endi Sukma Dewata wrote:
In the ticket I added 2 more scenarios to reproduce the problem. So we
have 3 possible cases:
1. invalid UI state
2. non-existent entry
3. server down
For case
On 03/19/2012 04:47 PM, Endi Sukma Dewata wrote:
ACK 106-1 and 111. See comments below.
Pushed to master, ipa-2-2.
On 3/16/2012 9:41 AM, Petr Vobornik wrote:
On 03/13/2012 10:54 PM, Endi Sukma Dewata wrote:
In the ticket I added 2 more scenarios to reproduce the problem. So we
have 3
On 3/19/2012 1:06 PM, Petr Vobornik wrote:
One more thing, this may not be a problem now, but the error_container
uses both facet-content and facet-error CSS classes. I understand this
is done to avoid code duplication, but this also means the facet will
have 2 facet-contents. CSS classes can be
On 03/13/2012 10:54 PM, Endi Sukma Dewata wrote:
On 3/9/2012 7:16 AM, Petr Vobornik wrote:
When an error which caused calling of report_error occur, the content of
a facet got replaced by error message. There was no way how to force the
facet to recreate its content and the facet became
On 3/9/2012 7:16 AM, Petr Vobornik wrote:
When an error which caused calling of report_error occur, the content of
a facet got replaced by error message. There was no way how to force the
facet to recreate its content and the facet became unusable.
This patch creates a container for an error
When an error which caused calling of report_error occur, the content of
a facet got replaced by error message. There was no way how to force the
facet to recreate its content and the facet became unusable.
This patch creates a container for an error message. On error,
report_error writes its
