Closed
Bug 48436
Opened 25 years ago
Closed 23 years ago
Change "Document: Done" to "Done"
Categories
(Core :: Networking, defect, P5)
Core
Networking
Tracking
()
VERIFIED
FIXED
mozilla1.2alpha
People
(Reporter: bugzilla, Assigned: Biesinger)
References
Details
Attachments
(1 file, 2 obsolete files)
(deleted),
patch
|
caillon
:
review+
bugzilla
:
superreview+
|
Details | Diff | Splinter Review |
Some discussion began to emerge in bug 47128 about whether we should stick with
4.x's silly "Document: Done" statusbar message. Splitting this off to cover
that issue. Maybe we should give some other wording a test run in pr3 and see
how users respond.
Comment 1•25 years ago
|
||
I bet they won't notice. But "done" is okay with me. (Or we could display random
off-the-wall quotations. Maybe some haiku status messages.)
Comment 2•25 years ago
|
||
Document is done
But it's bad HTML
So it won't look right
Reporter | ||
Comment 3•25 years ago
|
||
I'm really liking Vera's haiku idea, and the sample one that Matt gave was
great!
(Really, though, anyone strongly against or in support of making this change?
Matt, Brendan, German, John, Vera...?
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Comment 4•24 years ago
|
||
Strongly in support
(In fact, I was the one who
Proposed the idea)
Perhaps on Unix, each time a page finishes loading, we could fire up a new
instance of emacs in M-x zippy mode, to get a Zippy the Pinhead quote to use as
status text. It wouldn't be that good performance-wise, but it would bring a
whole new dimension to Web surfing.
I actually like Document: Done. I don't really care if it's changed though. Just
giving my two cents while I cc myself to this (might as well make that useless
cc email useful, huh?)
Reporter | ||
Updated•24 years ago
|
Priority: P3 → P2
Reporter | ||
Comment 6•24 years ago
|
||
and so for $1 mil, the final answer is...?
Comment 7•24 years ago
|
||
Going for one million dollars, going once, going twice ...
Done!
(By the way, the rest of Necko's status bar notifications could do with a lot of
work, too ...)
Comment 8•24 years ago
|
||
Open a new bug to "review/revise status bar messages" and assign it to me! I can
review them (and have the other writers and the editor look at them) as soon as
we get past the current crunch.
Reporter | ||
Updated•24 years ago
|
Priority: P2 → P4
Target Milestone: M18 → mozilla1.0
Reporter | ||
Comment 9•24 years ago
|
||
I'm starting to think differently about this. I know most of the majority of
status bar messages are for the document loading in the content area,
but "Done" doesn't seem very clear to me.
Priority: P4 → P5
Reporter | ||
Comment 10•24 years ago
|
||
Not sure I agree with this anymore...
Assignee: blakeross → ben
Status: ASSIGNED → NEW
Comment 11•24 years ago
|
||
So what should we use as a status message in the statusbar? anyone?
Comment 12•24 years ago
|
||
Depends on what the goal is. If you want to merely inidcate that the
(down)loading of the document has been completed , I think 'Done' something like
"Loading completed" is fine. This is not really something that can be usability
tested (by itself). Also please keep localization in mind, that is any changes
in structure of the statement (like adding new information) have to be reflected
in the 10+ or so languages that Moz/N6 get translated into.
Comment 13•24 years ago
|
||
perhaps:
Page: Downloaded (%X% elements remaining)
Page: Downloaded (%X% reflows expected)
Page: Refreshed (All page elements done refreshing)
Page: Loaded (Some objects are animating)
Page: Loaded (%X% script events remaining)
Page: Done (All page elements done loading)
Page: Done (All script events processed)
Page: Error (%X% errors encountered) [%lasterror%]
Summary: Change "Document: Done" to "Done" (or something else) ? → When is a document done? When is a door not a door?
Comment 14•24 years ago
|
||
I would like to replace "Page:" with "Document:" there, because not only pages
can be displayed with navigator.
Comment 15•24 years ago
|
||
I think the general idea is good but it is too technically worded. Who knows
what a reflow is? Not our general Netscape 6 user. Secondly I would stay away
from using a noun for the page altogether. That way it can be a plugin, a 3d
view or whatever document types get added later.
Also timeless, can you explain what you envision the different messages being
used for, and why you think it would be important for a common end user to have
all of these in there? Thanks.
Comment 16•24 years ago
|
||
I use page to mean the literal 'web page', whereas the document includes all of
its dependencies.
in which case, for Page: Done, i guess it should say Document: Done.
elements/objects remaining, if you watch IE load a page it tells you how many
items are left to load. Basic items are images, but also java apps, objects
css files, and iframes[?].
I'm not sure about reflows, but it would be nice if we could warn people that
the page is likely to rearrange itself shortly.
The animations and script information is to explain why the stop button is
enabled.
let's try a sample walk through.
<load http://localhost/mozilla/testSuite/>
Downloading Page: 50% of 100k (16bytes/sec).
Loading Document: 50 elements remaining. Loading Image: 90% of 16k (10k/sec).
...
Loading Document: 5 elements remaining, 1 reflow expected. Loading Style: 99%
of 20k (50k/sec).
Loaded Document: Done. Scripts: 5 events queued.
...
Document: Done. Scripts: 1 scheduled (starts: 30sec). Animations: 5 (stops:
45sec).
<stop>
Document: Stopped. Scripts: Terminated.
<reload>
{page sent w/ errors}
Error loading page: Missing <html>. 50 errors encountered.
<reload>
{page sent w/o errors}
Loading Page: from cache (1 sec).
Loading Document: 50 elements remaining. Loading Image: from cache (5 sec).
-- I don't have a better term for reflow, i'm hoping someone else could offer a
translation from en-Technical to en-US.
For one thing, we could have other details only display on mouse over (file/url
names, transfer rates) or toggle what displays on mouse click.
original:
Loading Document: 50 elements remaining. Loading Image: 90% of 16k (10k/sec).
alternative:
index.html: 10/100 loaded. background.png: 14/16k.
index.html: 10% loaded. background.png: 90% loaded.
index.html: 10sec elapsed (unknown). background.png: 2sec elapsed (1sec
remaining)
Comment 17•24 years ago
|
||
I really like the mouseover idea, that provides detail information on the item
being moused over.
I still think the scenario is way too verbose for the common user. I mean most
users do not even know what a script is or an event. They are not aware, because
that is not their mental model of how a page is displayed. To the extent where
we are talking only about a global number or items that are still loading that
is OK (like IE). Everything beyond that is a debugging aid for web developers
not a help for end users.
The other example were you are 'warning people that the page is likely to
rearrange itself shortly' is intimidating, even for me. Warning are issued where
you want to users to take preventive action or change the action they are
currently involved in, when in fact no such thing is required when loading a page.
I think we should keep things at a non-complex summary level for our end-users
rather than going into too many details.
For web developers a special browser pref could be added "Verbose status
messages", that could enable the rich detailed messages you are shwoing here.
Reporter | ||
Updated•24 years ago
|
Summary: When is a document done? When is a door not a door? → Change "Document: Done" to "Done" (or something else)?
Comment 18•24 years ago
|
||
This bug is just to change `Document: Done' to `Done'. Navigator's other
progress text is just as sub-optimal as `Document: Done' is, but that should be
the subject of separate bugs. (I have a spec for them lying around here
somewhere ...)
Comment 19•24 years ago
|
||
Done is a waste of a status line. we should make it blank when we're done. If
you have another bug that includes your spec please mention the number here and
we can spam it with all of the comments you want deported.
Comment 20•24 years ago
|
||
I completely disagree. First of all, I need some indication that it's done.
Second, where would we put that little clock?
As to removing "Document: ", I say leave it in. Is it really worth modifying?
Comment 21•24 years ago
|
||
The status bar should behave more like MSIE and NS4 while loading, e.g.:
Connecting to www.sitename.com
Transferring data from www.sitename.com
17/17 items remaining, transferring data from www.sitename.com
17/17 items remaining, 90% of index.html downloaded (8 seconds remaining)
17/17 items remaining, 97% of style.css downloaded (2 seconds remaining)
17/17 items remaining, 50% of picture1.jpg downloaded (1:15 remaining)
17/17 items remaining, 25% of picture2.jpg downloaded
For this last one it doesn't know how much time is left yet. It would loop
through all the different items one by one and come back to the original
"transferring data..." message.
...
1/17 items remaining, transferring data from www.sitename.com
1/17 items remaining, 75% of picture15.jpg downloaded (25 seconds remaining)
1/17 items remaining, 95% of picture15.jpg downloaded (5 seconds remaining)
And then, finally...
Done (17/17 items downloaded in 5:30)
For pages with only one item (e.g. downloading an image or plain text document),
the first part should be truncated unless or until another item is found. I
think the progress bar could be more accurate in this respect also, but I've
already gone too far off topic on this one.
Oh, and yes, of course the "Document: " should be dropped. In a sense, it could
actually be inaccurate since the progress indicator should also include things
outside of the document like the JS files and CSS files.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → Future
Comment 23•23 years ago
|
||
This should be done before 1.0, due to translation-freeze.
Can we nominate this for drivers and ADT ?
Comment 24•23 years ago
|
||
This patch changes the text from "Document: Done (%sec% secs)" to "Done (%sec%
seconds)".
This patch changes:
/xpfe/browser/resources/locale/en-US/navigator.properties
/xpfe/browser/resources/locale/en-US/navigator.dtd
I think the patch format is a bit cludgy, but it'll do.
Comment 25•23 years ago
|
||
ok, first of all, this patch isn't in the right format and i don't think it will
do. i will attach a cvs diff -u patch, i only want to know if we only change
this for navigator or also for messenger which has it's own "Document: Done"
entities (and i think we should change it everywhere, otherwise it's confusing).
Assignee: ben → rossi
Status: ASSIGNED → NEW
Comment 26•23 years ago
|
||
i made it for navigator and mailnews because i think you will all agree that we
should change it everywhere =)
obsoleting old patch, if you only want it for navigator i will attach a correct
format patch for navigator only.
Attachment #83516 -
Attachment is obsolete: true
Assignee | ||
Comment 27•23 years ago
|
||
Comment on attachment 84038 [details] [diff] [review]
patch for navigator & mailnews
r=biesi
Attachment #84038 -
Flags: review+
Assignee | ||
Updated•23 years ago
|
Summary: Change "Document: Done" to "Done" (or something else)? → Change "Document: Done" to "Done"
Comment 28•23 years ago
|
||
Comment on attachment 84038 [details] [diff] [review]
patch for navigator & mailnews
Why do we even have the Done (X.XX secs) in the first place? Let's do what
this bug suggests and actually make it just plain "Done".
Comment 29•23 years ago
|
||
Why modify the message to show less information than it does now? I'm sure
someone could find a use for that time display. If the change eliminates bloat,
it's good, but otherwise no harm in leaving it alone.
Comment 30•23 years ago
|
||
I like comment 21, but shouldn't that be a separate bug as
per comment 8?
I agree with the sentiment in comment 29: the time it took
the page to load is useful information, for web authors if
for nobody else, so unless removing it would noticeably
improve clarity or performance, I would like to see it
retained.
Assignee | ||
Comment 31•23 years ago
|
||
hwaara... this bug is not about removing the time, afaict. It's about removing
the "Document: " part of the status message.
Can we get it in? rossi, can you ask for sr?
Comment 32•23 years ago
|
||
Please get rid of the time. It's horribly inaccurate, and useless. Find me on
irc if you want to know why.
Assignee | ||
Comment 33•23 years ago
|
||
Attachment #84038 -
Attachment is obsolete: true
Comment 34•23 years ago
|
||
Comment on attachment 92717 [details] [diff] [review]
also removes the time
Looks safe and right. I double checked that all instances are accounted for.
r=caillon. (0.372 secs)
Attachment #92717 -
Flags: review+
Assignee | ||
Comment 35•23 years ago
|
||
blake, could you super-review the latest patch here?
Assignee: rossi → cbiesinger
Comment 36•23 years ago
|
||
And just why should we remove the time ? I want it there.
One acceptable solution is to move it to the Page Info dialog, but then that
should be done /before/ checking this in.
Comment 37•23 years ago
|
||
> And just why should we remove the time ?
Because it's deemed useless. I concur.
So the onus is on you: Why should we keep it? Is there any good reason other
than "because it's cool"? No, you aren't doing time analysis because if you
are, you wouldn't be trusting what we output.
Comment 38•23 years ago
|
||
Right.. I have no good reasons for keeping it, other than 'I want it' ;)
I just wanted some more discussion before it went in.
Reporter | ||
Updated•23 years ago
|
Attachment #92717 -
Flags: superreview+
Reporter | ||
Comment 39•23 years ago
|
||
Comment on attachment 92717 [details] [diff] [review]
also removes the time
sr=blake (.0371 secs) (that's why I'm a super-reviewer, caillon ;-)
Assignee | ||
Comment 40•23 years ago
|
||
tm -> 1.2alpha because that's when it will be checked in :)
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.2alpha
Assignee | ||
Comment 41•23 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 42•23 years ago
|
||
<sob> ... It's beautiful!
Verified fixed, build 2002081308, Mac OS 9.2.2.
Status: RESOLVED → VERIFIED
Comment 43•22 years ago
|
||
I miss the time display very much - I found it useful, in spite of it not being
totally accurate. If the lack accuracy was a reason to remove it, wouldn't it
have been enough to reduce the precision to, say, one tenth of a second, and
call it an approximation?
I must say that IME the lack of accuracy never made a quick site look slow, or
vice versa, so it can't have been that bad, IMHO.
Comment 44•22 years ago
|
||
If you'd like that to be changed, maybe you can tell us what you do that
requires the time display? That would make it more likely to happen.
Comment 45•22 years ago
|
||
I totally loved the time display. Have used it quite a bit while developing
phpBB (www.phpbb.com). I know, it's not very accurate, especially because it
includes network/server delays but it does give you a ballpoint figure when
trying different templates/stylesheets/JS code.
I would LOVE to have some kind of time statistics. It would be ideal if I could
see:
- Time between request and first reply from the webserver
- Transfer time (including bytes/sec)
- Time for parsing HTML
- Time for running scripts
- Time for rendering the HTML
- Time that was needed for waiting on additional page elements (i.e. images).
Would be fun if there was some kind of pref that would output above info to
some kind of debug console..
Any idea if this has been proposed before and if I should create a bug for this
or if I should first put this in the newsgroups? Have proposed this before but
didn't get any response on that. I really can't imagine that I'm the only
developer that needs this kind of information. Or am I the only person on this
world that is trying to optimize his web application for speed? :?
Comment 46•22 years ago
|
||
If you really want the time display back, open a new bug for it. This bug has
been fixed.
Comment 47•22 years ago
|
||
Re comment 46: - see bug 175231
Comment 48•22 years ago
|
||
BTW I opened bug 170284 for comment 45 some time ago.
You need to log in
before you can comment on or make changes to this bug.
Description
•